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

From: Boqun Feng

Date: Sat Aug 29 2026 - 17:15:50 EST


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