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

[Boqun Feng <boqun@kernel.org>]

On Sat, Aug 29, 2026 at 11:02:10PM +0200, Thomas Gleixner wrote:
> 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
> 

Will fix this.

> >     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.
> 

The link [1] here is for "the proper way to achieve this optimization
may need fixing up the counter at entry/exit time [1]", so I think
that's correct because it contains your explanation on how the fixup
would work. I will add a "Closes" tag to the other email that you
explained the issue. Sounds good?

Regards,
Boqun