Re: [PATCH v3 03/13] preempt: Introduce __preempt_count_{sub, add}_return()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Operator precedence bug in the commit message usage example.
--

commit 7f1eb356534806694deb9a4e04de28fe3e6692ab
Author: Boqun Feng <boqun@kernel.org>

preempt: Introduce __preempt_count_{sub, add}_return()

This commit introduces __preempt_count_add_return() and
__preempt_count_sub_return() to track the interrupt disable nesting level
while returning the new value of the preempt count. This helps avoid an
additional read of preempt_count() on certain architectures.

Link: https://patch.msgid.link/20260121223933.1568682-4-lyude@redhat.com

>     // if it's the first-time increment, then disable the interrupt
>     // at hardware level.
>     if (new_count & HARDIRQ_DISABLE_MASK == HARDIRQ_DISABLE_OFFSET) {
>             local_irq_save(flags);
>             raw_cpu_write(local_interrupt_disable_state.flags, flags);
>     }

[Severity: Low]
Is there an operator precedence issue in this usage example?

In C, the equality operator == has higher precedence than the bitwise
AND operator &. This means the expression evaluates as
new_count & (HARDIRQ_DISABLE_MASK == HARDIRQ_DISABLE_OFFSET). Since the
mask does not equal the offset, the equality evaluates to 0, making the
entire condition always false.

Should this be written with explicit parentheses like
(new_count & HARDIRQ_DISABLE_MASK) == HARDIRQ_DISABLE_OFFSET to prevent
readers from copying flawed logic into downstream implementations?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260605054128.5925-1-boqun@kernel.org?part=3