From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3EEFA3D890D for ; Tue, 25 Aug 2026 21:22:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787692941; cv=none; b=L0z+lDeRXHPBrZQJCjuKkWO5HIHNCtLqYNwPtlUaMu/5MlO5rCssO2gx3Kjucyg30FVQ7fzsc5oXKSHB/Qp//X+e6p3TSEYmc4gFa9flD7g7agBMEOW3TSolU1XlevET3z6pVTUEi1F/3Oti6InzgxlWovJ2gqKjUGyYJUOZ1E8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787692941; c=relaxed/simple; bh=WuNk+krd0znELbzxCLDlamMmt/lmJSQsKbVsmzBA+e8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=m82LBuEDEl0b4+8NmoJ5g950kUlbLvZjHGX+zC87nkoivUB/gfiOOBLrdbQO/aC2p5zPavop6HfuTT9WbiVdux+1VoLMqQYoN9ecC6tFVx7CjxI0OPTQ2pn2gq+Roo7mkROdHh5TK4wOAALLYHZ34xQplXqw0dvh8vcdP+HZHjE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Hk9cK64d; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Hk9cK64d" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B08041F000E9; Tue, 25 Aug 2026 21:22:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1787692938; bh=+UXtRq22TLXGCAHOmkNqPtVMN4w4P727MjoczrbR+O4=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=Hk9cK64dyeKZM/mkVEUbCn9T5LBHKp2xi/lMtks/2/tvtjOC89k7JXh/7+7qIXaDG blZg1fI8YEIW+Sb0gFzQ6IhWaVq4QZk/kDCvqIx6xKdPDQACQiLFxrJDM5FiuJ+rXP WhKX9q9oQr+FMqp8YjGVm9D6uXUlOfjO10wC+DLaUJnfnhWsVmn/gZdLIqs4F2Cel/ 8Qo07Qo7BQYtScUqOwVH36HDKzDitNimI8ysOPrrZdNlPMs2K+p3xUjUG5yHevFLxK XBIO4nx29QVxwmUwwTL4cvVzkoma2h+9+ZLC2QXgha/zpSTOgXA9nxWCvVOBRYsMm5 xVoiD87WjFTPw== From: Thomas Gleixner To: pavankumaryalagada@gmail.com, anna-maria@linutronix.de Cc: frederic@kernel.org, linux-kernel@vger.kernel.org, skhan@linuxfoundation.org, Yalagada Pavan Kumar , syzbot+143e0859898751aa8f94@syzkaller.appspotmail.com, Boqun Feng , Peter Zijlstra Subject: Re: [PATCH] posix-timers: fix IRQ state handling in posix_timer_delete() In-Reply-To: <20260825200626.139243-1-pavankumaryalagada@gmail.com> References: <20260825200626.139243-1-pavankumaryalagada@gmail.com> Date: Tue, 25 Aug 2026 23:22:15 +0200 Message-ID: <87a4q9hp4o.ffs@fw13> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Wed, Aug 26 2026 at 01:36, pavankumaryalagada@gmail.com wrote: > From: Yalagada Pavan Kumar > > 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@syzkaller.appspotmail.com > Closes: https://syzkaller.appspot.com/bug?extid=143e0859898751aa8f94 > Tested-by: syzbot+143e0859898751aa8f94@syzkaller.appspotmail.com > Signed-off-by: Yalagada Pavan Kumar 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