Re: [PATCH] locking: Revert switching guards to _irq_{disable,enable}()

[Thomas Gleixner]

On Thu, Aug 27 2026 at 09:52, Boqun Feng wrote:
> On Thu, Aug 27, 2026 at 05:43:26PM +0200, Thomas Gleixner wrote:
>> But coming back to the problem underneath. The ordering in
>> local_interrupt_disable() is simply wrong. You need to disable first and
>> then update the counter. Reverse order for enable() obviously update
>> counter and enable, which you got right.
>> 
>
> Noted, the reason that I used the current order is to optimize
> local_interrupt_disable() from re-disabling interrupt every time:
>
> 	https://lore.kernel.org/rust-for-linux/87a5eu7gvw.ffs@tglx/

Yes. I gave you the wrong order, but I expected you to actually think it
through and not blindly copy it. :)

> but looks like we cannot do it without the fixups you mention below.

But that does not mean it can't be done. Checking for 0 first and
incrementing after the actual disable is still achieving the same result
of touching the CPU only once, no?

> For now I will reverse the order and remove the additional checking in
> softirq to fix the softirq pending issue.

That "fixes" another nasty bug which was latent for weeks and people
could not get a handle on it because it was absolutely not
reproducible. Given all that I'm absolutely not convinced that there
isn't another pile of latent surprises lurking.

Aside of that I'm worried about having this new counter exposed in the
current state of affairs. Nothing prevents arbitrary code from using
hardirq_disable_count(), which is definitely faster than
irqs_disabled(), but returns a random value depending on context. That's
just another recipe for latent and hard to debug disasters to happen as
you already demonstrated in __irq_exit_rcu().

It's not the end of the world to bite the bullet and undo the whole
pile, except for the then unused expansion of preempt count, go back to
the drawing board and come up with a consistent and better overall
solution.

I know that hurts, I've been there myself more than once. But at the end
I was always happy that we decided to rip it out instead of trying to
debug and duct tape it to death.

A inconsistent and fragile facility is worse than having none.

Thanks,

        tglx