Re: [PATCH v2 05/12] irq & spin_lock: Add counted interrupt disabling/enabling

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] An NMI occurring inside local_interrupt_enable() corrupts the per-CPU saved IRQ flags, leading to permanently disabled hardware interrupts.
- [High] Skipping softirq processing in `__irq_exit_rcu()` without re-triggering it in `local_interrupt_enable()` leads to indefinite softirq starvation.
--

commit 2a089d1e2525d387b14ef2c6eb7f3576f07d6bc4
Author: Boqun Feng <boqun@kernel.org>

irq & spin_lock: Add counted interrupt disabling/enabling

This commit introduces new local interrupt disabling APIs that use a per-CPU
counter to support nesting. This avoids accidental early interrupt enabling
when locks are nested or used with guard facilities.

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

> diff --git a/include/linux/interrupt_rc.h b/include/linux/interrupt_rc.h
> new file mode 100644
> --- /dev/null
> +++ b/include/linux/interrupt_rc.h
[ ... ]
> +static inline void local_interrupt_enable(void)
> +{
> +	int new_count;
> +
> +	new_count = hardirq_disable_exit();
> +
> +	if ((new_count & HARDIRQ_DISABLE_MASK) == 0) {
> +		unsigned long flags;
> +
> +		flags = raw_cpu_read(local_interrupt_disable_state.flags);

[Severity: Critical]
Can the per-CPU saved IRQ flags be corrupted if an NMI occurs here?

After hardirq_disable_exit() decrements the count to zero, but before the
saved flags are read, there is an unprotected window. If an NMI fires in
this window, the interrupted thread's count is 0 but its hardware IRQs are
still disabled.

If the NMI handler or a function it calls uses local_interrupt_disable() or
spin_lock_irq_disable(), it will see the count is 0, assume it is the
outermost caller, and overwrite the per-CPU flags with its own IRQ state.

Since hardware IRQs were disabled when the NMI hit, the saved flags will
reflect disabled IRQs. When the NMI returns, the interrupted thread reads
these corrupted per-CPU flags and passes them to local_irq_restore(),
which would permanently disable hardware interrupts on that CPU.

> +		local_irq_restore(flags);
> +		/*
> +		 * TODO: re-read preempt count can be avoided, but it needs
> +		 * should_resched() taking another parameter as the current
> +		 * preempt count
> +		 */
> +#ifdef CONFIG_PREEMPTION
> +		if (should_resched(0))
> +			__preempt_schedule();
> +#endif
> +	}
> +}

[ ... ]
> diff --git a/kernel/softirq.c b/kernel/softirq.c
> index 10af5ed859e73..d1ab1799794ca 100644
> --- a/kernel/softirq.c
> +++ b/kernel/softirq.c
[ ... ]
> @@ -728,7 +731,16 @@ static inline void __irq_exit_rcu(void)
>  #endif
>  	account_hardirq_exit(current);
>  	preempt_count_sub(HARDIRQ_OFFSET);
> -	if (!in_interrupt() && local_softirq_pending()) {
> +	/*
> +	 * Interrupts may happen between hardirq_disable_enter() and
> +	 * local_irq_save() in local_interrupt_disable(), if irq_exit() invokes
> +	 * softirq here, we may have a softirq handler calling
> +	 * local_interrupt_disable() but it won't disable the irq because
> +	 * hardirq disabling count is already 1, hence we need to prevent
> +	 * invoking softirq when a local_interrupt_disable() is ongoing.
> +	 */
> +	if (!in_interrupt() && !hardirq_disable_count() &&
> +	    local_softirq_pending()) {

[Severity: High]
Does skipping softirq processing here lead to indefinite softirq starvation?

By skipping invoke_softirq() when hardirq_disable_count() > 0, any scheduled
softirqs (such as timers, RCU callbacks, or networking) are left pending.

When the critical section ends, local_interrupt_enable() decrements the
count and re-enables hardware interrupts, but it does not check
local_softirq_pending() to flush these deferred softirqs.

Will these pending softirqs stall indefinitely until another, unrelated
hardware interrupt fires, potentially causing RCU stalls or network hangs
in low-activity periods?

>  		/*
>  		 * If we left hrtimers unarmed, make sure to arm them now,
>  		 * before enabling interrupts to run SoftIRQ.

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