Re: [syzbot] [sound?] possible deadlock in __snd_pcm_lib_xfer (2)

Hillf Danton
2025-09-05T03:04:48Z

On Thu, 4 Sep 2025 08:12:45 +0200 Sebastian Andrzej Siewior wrote:
> On 2025-09-04 09:05:28 [+0800], Hillf Danton wrote:
> > 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
> > > > > ---- ----
> Thead0 Thread1
> ------ -------c
> > > > > lock(&group->lock#2);
> preempt to ->
> > > > > lock((softirq_ctrl.lock));
> > > > > lock(&group->lock#2);
> <- preempt to
> > > > > lock((softirq_ctrl.lock));
> > > > >
> > > > > *** DEADLOCK ***
> now nobody makes progress
>
Because of the absense of the deadlock detecting mechanism in timer, see
lock_map_acquire() in call_timer_fn() for detail, hrtimer is unable to
detect deadlock like the reported one.

CPU0 CPU1
---- ----
lock A hrtimer B callback
cancel hrtimer B lock A

On the other hand softirq_ctrl plays such a detecting role in accident, but
they are two entirely different things.