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

[Boqun Feng]

On Mon, Aug 31, 2026 at 12:02:50PM +0200, Thomas Gleixner wrote:
> On Sun, Aug 30 2026 at 14:23, Boqun Feng wrote:
> > On Sun, Aug 30, 2026 at 09:57:30PM +0200, Thomas Gleixner wrote:
> >> The actual PREEMPT_COUNT_IRQFLAGS thing will be 7.4 material obviously
> >> and as this is confined to Rust then it's trivial enough to work around
> >> it locally without exposing more stuff. See tiny delta patch below.
> >> 
> >> So the only side effect of that is that the Rust implementation will not
> >> be fully integrated into the preempt count magic, but it should just
> >> work, no?
> >> 
> >
> > Right, that works. It's similar to the "alternatively" approach I
> > mentioned here [1].
> 
> But thinking more about it. It actually just works with the preempt
> count bits independent of PREEMPT_COUNT_IRQFLAGS.
> 
> For PREEMPT_COUNT_IRQFLAGS=n, Rust is the only one using it.
> 
> For PREEMPT_COUNT_IRQFLAGS=y, the Rust part integrates with the core
> implementation. And once all Rust supporting architectures are enabling
> PREEMPT_COUNT_IRQFLAGS the Rust extra magic goes away.
> 
> No?
> 

Right, that's why I thought fully revert on commit e901c1510e24 might
not be needed.

To me, the only "magic" part when PREEMPT_COUNT_IRQFLAGS=n are 1)
preempt_count() is inconsistent on HARDIRQ_DISABLE_MASK about interrupt
disabling as you pointed out earlier and 2)
local_interrupt_{en,dis}able() has to save the current irq disabling
state/flag to work with local_irq_*(). PREEMPT_COUNT_IRQFLAGS=y resolves
both of them.

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.

Hope this makes sense.

Regards,
Boqun

> Thanks,
> 
>         tglx
> 
>