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

[Boqun Feng]

On Sun, Aug 30, 2026 at 09:57:30PM +0200, Thomas Gleixner wrote:
> On Sun, Aug 30 2026 at 08:18, Boqun Feng wrote:
> > On Sat, Aug 29, 2026 at 04:37:37PM -0700, Boqun Feng wrote:
> >> And while we are at, we can just introduce a
> >> raw_local_irq_restore_auto() (definitely needs a better name), which
> >> doesn't need a cnt:
> >>
> >> static __always_inline void __raw_local_irq_restore_auto(void)
> >> {
> >> 	debug_assert((preempt_count() & HARDIRQ_DISABLE_MASK));
> >> 
> >> 	if (!(__preempt_count_sub_return(HARDIRQ_DISABLE_OFFSET) & HARDIRQ_DISABLE_MASK))
> >> 		arch_local_irq_enable();
> >> }
> 
> Can we just make the thing work in the first place?
>  

Yes, for sure.

> >> And we can slowly convert irq_restore() users to use it?
> 
> Somewhere down the road.
> 
> > I decided to use local_irq_resume(), not sure whether it's a good name
> > either...
> >
> > If we are OK to not fully revert on commit e901c1510e24 ("irq,spin_lock:
> > Add counted interrupt disabling/enabling"), I think the following will
> > resolve the 0day built errors on your irqflags branch (I rebased onto
> > tip/locking/urgent with rest of your series on irqflags branch). A few
> > things to notice:
> 
> The zero day failure is not due to that. It's because I reverted that
> refcounted muck as well in my git tree.
> 

Right, that's why I said "if we are OK to not fully revert commit
e901c1510e24 ...", but your movestuff.patch should works as well.

> I just rebased the series on top of tip locking/urgent, which only has
> the irq,spinlock revert and your patches on top.
> 
> > * I haven't found a way that we can do a local_irq_resume() when
> >   !CONFIG_PREEMPT_COUNT_IRQFLAGS, and if we cannot, it's going to make
> >   part of Rust code depends on CONFIG_PREEMPT_COUNT_IRQFLAGS=y
> 
> That's a good thing as it might make people actually get their act
> together. And you can work around that in interrupt_rc.h itself.
> 
> Can you please stop bouncing around like a rubber ball and take your
> time?
> 

Apologies. I was just trying to help (and explore myself) the
integration of PREEMPT_COUNT_IRQFLAGS with local_interrupt_disable(),
it's merely some food for thoughts...

> First of all I want to move interrupt_rc.h and the whole spinlock muck
> into rust/helpers/ now. Why?
> 
> Simply because it is Rust only and we don't want to expose any of this
> stuff to random driver writers. See attached patch.
> 

Sure. I will give the movestuff.patch some test.

> I've rebased my devel branch on top of tip/locking/urgent and applied
> that patch so the robots can have their field day.
> 
> 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].

> And when an architecture supports the real thing then it gets all the
> benefits with bells and whistels.
> 
> I really want to get the PREEMPT_COUNT_IRQFLAGS design right first and
> then we can think about simplifications and cleanups and remove the
> whole Rust magic once all architectures which support Rust play along.
> 

Yeah, that's a better plan. 

[1]: https://lore.kernel.org/lkml/apCS3T63WUxHd1GH@tardis.local/

Regards,
Boqun

> Thanks,
> 
>         tglx
> 
> ---
[...]