Re: [PATCH] posix-timers: fix IRQ state handling in posix_timer_delete()
From: Thomas Gleixner
Date: Tue Aug 25 2026 - 17:22:27 EST
On Wed, Aug 26 2026 at 01:36, pavankumaryalagada@xxxxxxxxx wrote:
> From: Yalagada Pavan Kumar <pavankumaryalagada@xxxxxxxxx>
>
> exit_itimers() uses a spinlock_irq guard for timer->it_lock, which
> maintains counted IRQ-disable state. However, posix_timer_delete()
> temporarily releases and reacquires the lock with spin_unlock_irq()
> and spin_lock_irq(), which do not maintain the same IRQ-disable state
> while timer_wait_running() may sleep.
>
> Use spin_unlock_irq_enable() and spin_lock_irq_disable() for the
> temporary lock handoff to keep the IRQ-disable state balanced.
>
> Reported-by: syzbot+143e0859898751aa8f94@xxxxxxxxxxxxxxxxxxxxxxxxx
> Closes: https://syzkaller.appspot.com/bug?extid=143e0859898751aa8f94
> Tested-by: syzbot+143e0859898751aa8f94@xxxxxxxxxxxxxxxxxxxxxxxxx
> Signed-off-by: Yalagada Pavan Kumar <pavankumaryalagada@xxxxxxxxx>
This clearly lacks a "Fixes:" tag and you failed to actually CC the
relevant people, but see below.
> ---
> kernel/time/posix-timers.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/time/posix-timers.c b/kernel/time/posix-timers.c
> index 436ba794cc0b..5e580b4223de 100644
> --- a/kernel/time/posix-timers.c
> +++ b/kernel/time/posix-timers.c
> @@ -1057,9 +1057,9 @@ static void posix_timer_delete(struct k_itimer *timer)
>
> while (timer->kclock->timer_del(timer) == TIMER_RETRY) {
> guard(rcu)();
> - spin_unlock_irq(&timer->it_lock);
> + spin_unlock_irq_enable(&timer->it_lock);
> timer_wait_running(timer);
> - spin_lock_irq(&timer->it_lock);
> + spin_lock_irq_disable(&timer->it_lock);
> }
> }
While this is curing the symptom, it's not fixing the root cause. The
root cause is that the conversion of just the lock guards does not cut
it. This particular case in posix_timer_delete() is just the tip of the
iceberg and an easy one to trigger. The whole conversion is not really
well thought out and lacks any form of static analysis. Therefore the
actual culprit got reverted and will hit Linus tree soon:
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?h=locking/urgent
Thanks,
tglx