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

[Thomas Gleixner]

> On Mon, Aug 31, 2026 at 12:02:50PM +0200, Thomas Gleixner wrote:
> Right, that's why I thought fully revert on commit e901c1510e24 might
> not be needed.

It's gone already and as I told you before the reason is that the issues
were not restricted to the ordering parts v.s. count/hardware and the
fallout in the softirq code. The whole issue with nested unlock/lock
inside a guard are not solved by reordering local_interrupt_disable().
Not to talk about the lack of proper debug features for it.

> And if PREEMPT_COUNT_IRQFLAGS=y is the future (i.e. it'll be always y),
> then we will likely have local_interrupt_{en,dis}able() (or a different
> name) as a general API for everyone. So the API (and its semantics) is
> not Rust-specific considering the future direction. Hence previously I
> said that we can move them to Rust only but seems a bit unnecessary to
> me.

No. We need a proper strategy to pull that off and not exposing the
functionality and the name right now outside of Rust makes that way
simpler. Changing Rust is one thing, chasing down a pile of random use
cases which crept in _before_ the design and strategy is settled is a
completely different story.

Thanks,

        tglx