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

[Boqun Feng]

On Tue, Aug 25, 2026 at 04:28:59PM -0700, Boqun Feng wrote:
> On Wed, Aug 26, 2026 at 12:59:25AM +0200, Thomas Gleixner wrote:
> > On Mon, Aug 24 2026 at 18:33, Boqun Feng wrote:
> > > On Mon, Aug 24, 2026 at 12:55:23PM +0200, Peter Zijlstra wrote:
> > >> 
> > >> While the guards are properly nested, not all wrapped code is nice, as already
> > >> highlighted by that fair.c hunk.
> > >> 
> > >> Syzbot found another instance of this pattern in posix_timer_delete(), which
> > >> does spin_unlock_irq()+spin_lock_irq() inside scoped_guard(spinlock_irq).
> > >> Combined with this patch, that goes sideways most spectacular.
> > >> 

I'm not saying the posix_timer_delete() implementation has any problem,
but TBH allowing spin_unlock_irq()+spin_lock_irq() inside
scoped_guard(spinlock_irq) is questionable design, and can result into
foot-gun code like:

	scoped_guard(spinlock_irq) {
		...
		spin_unlock_irq();
		if (cond)
			return; // BOOM, double unlock
		spin_lock_irq();
	}

Sure, if handling carefully, it won't cause problem, but it undermines
the easy-to-use and less-err-prone features of scoped_guard().

Regards,
Boqun

> > >> Undo this change, until we've developed stronger tools / debug for such issues.
> > >> 
> > >
> > > Mainly hand-waving, but if we make _irq(), irqsave(), _disable()
> > > __acquires() different contexts, we may be able to catch these issues at
> > > compile time. I will explore a bit on this.
[...]