Re: possible deadlock in _snd_pcm_stream_lock_irqsave

[Boqun Feng]

Thanks for reporting.

On Wed, Sep 09, 2020 at 10:33:04AM -0700, syzbot wrote:
> syzbot has bisected this issue to:
> 
> commit e918188611f073063415f40fae568fa4d86d9044
> Author: Boqun Feng <boqun.feng@xxxxxxxxx>
> Date:   Fri Aug 7 07:42:20 2020 +0000
> 
>     locking: More accurate annotations for read_lock()
> 
> bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=112dc243900000
> start commit:   dff9f829 Add linux-next specific files for 20200908
> git tree:       linux-next
> final oops:     https://syzkaller.appspot.com/x/report.txt?x=132dc243900000
> console output: https://syzkaller.appspot.com/x/log.txt?x=152dc243900000

>From what I see in the output, probably this is the new deadlock
possibility we find with lockdep, basically if we have:

	CPU 0:					CPU 1:
	read_lock(snd_card::ctl_file_rwlock);
						<irq disabled>
						spin_lock(snd_pcm_group::lock);
						read_lock(snd_card::ctl_file_rwlock);
	<interrupted by softirq>
	spin_lock(snd_pcm_group::lock);

, because the read_lock() on CPU 1 will be a fair read lock(IOW, not a
recursive reader). And if there is a third CPU is also waiting for the
write_lock(), CPU 1 cannot get the read_lock() due to the fairness:

	CPU 0:					CPU 1:					CPU 2:
	read_lock(snd_card::ctl_file_rwlock);
						<irq disabled>
						spin_lock(snd_pcm_group::lock);
											write_lock(snd_card::ctl_file_rwlock);
						read_lock(snd_card::ctl_file_rwlock); // fair read lock, can only get the lock if CPU 2 get its lock
	<interrupted by softirq>
	spin_lock(snd_pcm_group::lock);

That said, I'm still looking into the code to find whether there is a
lock combination of CPU 1. Given I'm not familiar with sound subsystem,
I will appreciate any help on finding the lock pattern on CPU 1 ;-)

Regards,
Boqun

> kernel config:  https://syzkaller.appspot.com/x/.config?x=37b3426c77bda44c
> dashboard link: https://syzkaller.appspot.com/bug?extid=561a74f84100162990b2
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=1209e245900000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=154b15ed900000
> 
> Reported-by: syzbot+561a74f84100162990b2@xxxxxxxxxxxxxxxxxxxxxxxxx
> Fixes: e918188611f0 ("locking: More accurate annotations for read_lock()")
> 
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection