Re: [PATCH v3 07/13] locking: Switch to _irq_{disable,enable}() variants in cleanup guards

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Switching `guard(raw_spinlock_irqsave)` and `guard(spinlock_irqsave)` to use `_irq_disable()` variants breaks NMI-safety and will trigger WARN splats and potential `preempt_count` corruption when used in NMI context.
--

commit 545c01b2eb680702b0d892d04382c1e8bb27b35f
Author: Boqun Feng <boqun@kernel.org>

locking: Switch to _irq_{disable,enable}() variants in cleanup guards

This commit modifies various irq disabling guards to use the
_irq_{disable,enable}() primitives instead of their previous variants.

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

> diff --git a/include/linux/spinlock.h b/include/linux/spinlock.h
> index 3d405cc4c1218..799a8f7d27418 100644
> --- a/include/linux/spinlock.h
> +++ b/include/linux/spinlock.h

[ ... ]

> @@ -592,14 +592,13 @@ DECLARE_LOCK_GUARD_1_ATTRS(raw_spinlock_bh_try, __acquires(_T), __releases(*(raw
>  #define class_raw_spinlock_bh_try_constructor(_T) WITH_LOCK_GUARD_1_ATTRS(raw_spinlock_bh_try, _T)
>  
>  DEFINE_LOCK_GUARD_1(raw_spinlock_irqsave, raw_spinlock_t,
> -		    raw_spin_lock_irqsave(_T->lock, _T->flags),
> -		    raw_spin_unlock_irqrestore(_T->lock, _T->flags),
> -		    unsigned long flags)
> +		    raw_spin_lock_irq_disable(_T->lock),
> +		    raw_spin_unlock_irq_enable(_T->lock))

[Severity: High]
Does this change break NMI-safety for users of guard(raw_spinlock_irqsave)?

The raw_spin_lock_irqsave primitive relies exclusively on CPU-local hardware
flag saving, which makes it safe for use in any context, including NMIs.

By switching to raw_spin_lock_irq_disable, this completely bypasses local
flags saving and relies on local_interrupt_disable() under the hood.

Because local_interrupt_disable() manipulates the task's preempt_count via
hardirq_disable_enter(), it isn't safe in NMI context and will trigger a
WARN_ON_ONCE(in_nmi()) splat and potential preempt_count corruption.

>  DECLARE_LOCK_GUARD_1_ATTRS(raw_spinlock_irqsave, __acquires(_T), __releases(*(raw_spinlock_t **)_T))
>  #define class_raw_spinlock_irqsave_constructor(_T) WITH_LOCK_GUARD_1_ATTRS(raw_spinlock_irqsave, _T)

[ ... ]

> @@ -640,14 +639,13 @@ DECLARE_LOCK_GUARD_1_ATTRS(spinlock_bh_try, __acquires(_T), __releases(*(spinloc
>  #define class_spinlock_bh_try_constructor(_T) WITH_LOCK_GUARD_1_ATTRS(spinlock_bh_try, _T)
>  
>  DEFINE_LOCK_GUARD_1(spinlock_irqsave, spinlock_t,
> -		    spin_lock_irqsave(_T->lock, _T->flags),
> -		    spin_unlock_irqrestore(_T->lock, _T->flags),
> -		    unsigned long flags)
> +		    spin_lock_irq_disable(_T->lock),
> +		    spin_unlock_irq_enable(_T->lock))

[Severity: High]
Will this also cause preempt_count corruption and WARN splats in NMI context
for guard(spinlock_irqsave)?

Similar to the raw_spinlock_irqsave change above, moving away from the true
irqsave mechanism violates the contract that irqsave constructs are entirely
context-agnostic.

>  DECLARE_LOCK_GUARD_1_ATTRS(spinlock_irqsave, __acquires(_T), __releases(*(spinlock_t **)_T))
>  #define class_spinlock_irqsave_constructor(_T) WITH_LOCK_GUARD_1_ATTRS(spinlock_irqsave, _T)

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