Thanks!

On Wed, Sep 09, 2020 at 06:19:06AM -0700, syzbot wrote:
> syzbot has bisected this issue to:
> 
> commit f08e3888574d490b31481eef6d84c61bedba7a47
> Author: Boqun Feng <boqun.f...@gmail.com>
> Date:   Fri Aug 7 07:42:30 2020 +0000
> 
>     lockdep: Fix recursive read lock related safe->unsafe detection
> 
> bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=13034be1900000
> start commit:   dff9f829 Add linux-next specific files for 20200908
> git tree:       linux-next
> final oops:     https://syzkaller.appspot.com/x/report.txt?x=10834be1900000
> console output: https://syzkaller.appspot.com/x/log.txt?x=17034be1900000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=37b3426c77bda44c
> dashboard link: https://syzkaller.appspot.com/bug?extid=22e87cdf94021b984aa6
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=108b740d900000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=12daa9ed900000
> 
> Reported-by: syzbot+22e87cdf94021b984...@syzkaller.appspotmail.com
> Fixes: f08e3888574d ("lockdep: Fix recursive read lock related safe->unsafe 
> detection")
> 

This is another deadlock possibility detected by lockdep's new detection
algorithm.

The deadlock happens as follow:

        CPU 0                           CPU 1                   CPU 2
        read_lock(&fown->lock);
                                        spin_lock_irqsave(&dev->event_lock, ...)
                                                                
write_lock_irq(&filp->f_owner.lock); // wait for the lock
                                        read_lock(&fown-lock); // have to wait 
until the writer release
                                                               // due to the 
fairness
        <interrupted>
        spin_lock_irqsave(&dev->event_lock); // wait for the lock

The lock dependency on CPU 1 happens if there exists a call sequence:

        input_inject_event():
          spin_lock_irqsave(&dev->event_lock,...);
          input_handle_event():
            input_pass_values():
              input_to_handler():
                handler->event(): // evdev_event()
                  evdev_pass_values():
                    spin_lock(&client->buffer_lock);
                    __pass_event():
                      kill_fasync():
                        kill_fasync_rcu():
                          read_lock(&fa->fa_lock);
                          send_sigio():
                            read_lock(&fown->lock);

A possible fix would be replacing the read_lock() with read_lock_irq()
or read_lock_irqsave().

Regards,
Boqun

> For information about bisection process see: https://goo.gl/tpsmEJ#bisection

Reply via email to