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

[Thomas Gleixner <tglx@kernel.org>]

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.
>> 
>> 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.

No.

Just do a wholesale conversion of all functions which affect the CPU
interrupt disabled state directly (local_irq_*) and indirectly (locking
functions etc.)

Anything else is just a whack a mole game.

TBH, I do not understand why you thought that you can get away with this
lazy approach especially after you discovered the same nasty problem in
do_sched_cfs_period_timer(). The resolution of that got buried in

  1b0866874833 ("locking: Switch to _irq_{disable,enable}() variants in cleanup guards")

without even being mentioned.

When I was discussing the non-sensical syzbot messages earlier today
with Peter it immediately occurred to me that this undocumented change in
do_sched_cfs_period_timer() is not the only pattern which causes this to
go belly up. It took me five seconds to find the posix timer one.

TBH, my hope really was that the RUST people take the only valid
engineering principle "Correctness first" serious, but sadly they seem
to be the same lazy sods than everyone else who want to push their
agenda through no matter what.

Thanks,

        tglx