[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250904010529.6410-1-hdanton@sina.com>
Date: Thu, 4 Sep 2025 09:05:28 +0800
From: Hillf Danton <hdanton@...a.com>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: syzbot <syzbot+10b4363fb0f46527f3f3@...kaller.appspotmail.com>,
linux-kernel@...r.kernel.org,
syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [sound?] possible deadlock in __snd_pcm_lib_xfer (2)
On Wed, 3 Sep 2025 16:59:05 +0200 Sebastian Andrzej Siewior wrote:
> On 2025-08-30 14:56:37 [+0800], Hillf Danton wrote:
> > > syz.0.46/6843 is trying to acquire lock:
> > > ffff8880b8823d90 ((softirq_ctrl.lock)){+.+.}-{3:3}, at: spin_lock include/linux/spinlock_rt.h:44 [inline]
> > > ffff8880b8823d90 ((softirq_ctrl.lock)){+.+.}-{3:3}, at: __local_bh_disable_ip+0x264/0x400 kernel/softirq.c:168
> > >
> > Given softirq_ctrl is percpu, this report is false positive.
>
> No. This can happen on a single CPU.
>
But the single CPU theory fails to explain the deadlock reported.
> > > Possible unsafe locking scenario:
> > >
> > > CPU0 CPU1
> > > ---- ----
> > > lock(&group->lock#2);
> > > lock((softirq_ctrl.lock));
> > > lock(&group->lock#2);
> > > lock((softirq_ctrl.lock));
> > >
> > > *** DEADLOCK ***
Powered by blists - more mailing lists