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.f...@gmail.com>
> 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+561a74f8410016299...@syzkaller.appspotmail.com
> Fixes: e918188611f0 ("locking: More accurate annotations for read_lock()")
>
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection
