Re: [PATCH] interrupt: Disable interrupt before modifying hardirq_disable counter

[Thomas Gleixner]

On Thu, Aug 27 2026 at 11:10, Boqun Feng wrote:
> Currently a softirq may be pending longer then expected if the
> triggering interrupt happens in-between hardirq_disable_enter() and
> _local_interrupt_disable() in local_interrupt_disable():
>
>     local_interrupt_disable():
>       hardirq_disable_enter();
>       <interrupt>
>       ...
>       __irq_exit_rcu():
>         // false because hardirq_disable_count() is not 0
>         if (.. && !hardirq_disable_count() && ..) {
> 	  invoke_softirq();
> 	}
>       _local_interrupt_disable();
>
> , it'll defer the softirq to the next interrupt which can be forever.
>
> The order between hardirq_disable_enter() and _local_interrupt_disable()
> is to optimize re-disabling interrupts if they are already disabled, but
> as 1) local_interrupt_disable() is not widely used yet and 2) the proper
> way to achieve this optimization may need fixing up the counter at
> entry/exit time [1], so reverse the order for now to avoid the softirq
> pending issue.
>
> Since we are doing this, the part of saving the current state is
> separated from irq disabling, and we basically do the following in
> local_interrupt_disable():

We do nothing. See

https://docs.kernel.org/process/maintainer-tip.html#changelog

>     local_irq_save(flags);
>     if (counter++ == 0) {
>       this_cpu(local_interrupt_disable_state) = flags;
>     }
>
> Change _local_interrupt_disable() to _local_interrupt_save_state().
>
> Link: https://lore.kernel.org/lkml/87v78wezid.ffs@fw13/ [1]

  https://lore.kernel.org/lkml/87jypbfu1t.ffs@fw13/

is the mail where I explained that softirq issue.