From: Boqun Feng <boqun.feng@gmail.com>
To: syzbot <syzbot+22e87cdf94021b984aa6@syzkaller.appspotmail.com>
Cc: bfields@fieldses.org, jlayton@kernel.org,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
mingo@redhat.com, peterz@infradead.org,
syzkaller-bugs@googlegroups.com, viro@zeniv.linux.org.uk,
will@kernel.org
Subject: Re: WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected (2)
Date: Thu, 10 Sep 2020 15:15:23 +0800 [thread overview]
Message-ID: <20200910071523.GF7922@debian-boqun.qqnc3lrjykvubdpftowmye0fmh.lx.internal.cloudapp.net> (raw)
In-Reply-To: <000000000000d7136005aee14bf9@google.com>
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@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+22e87cdf94021b984aa6@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
prev parent reply other threads:[~2020-09-10 7:16 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-09 8:48 WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected (2) syzbot
2020-09-09 13:19 ` syzbot
2020-09-10 7:15 ` Boqun Feng [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200910071523.GF7922@debian-boqun.qqnc3lrjykvubdpftowmye0fmh.lx.internal.cloudapp.net \
--to=boqun.feng@gmail.com \
--cc=bfields@fieldses.org \
--cc=jlayton@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=syzbot+22e87cdf94021b984aa6@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=viro@zeniv.linux.org.uk \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).