Re: WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected (2)

[Boqun Feng]

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.feng@xxxxxxxxx>
> 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+22e87cdf94021b984aa6@xxxxxxxxxxxxxxxxxxxxxxxxx
> 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