From: Greg KH <gregkh@linuxfoundation.org>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Andrey Konovalov <andreyknvl@google.com>,
Oliver Neukum <oneukum@suse.com>,
syzkaller-bugs <syzkaller-bugs@googlegroups.com>,
USB list <linux-usb@vger.kernel.org>
Subject: Re: [PATCH] USB: rio500: Fix lockdep violation
Date: Tue, 3 Sep 2019 20:18:53 +0200 [thread overview]
Message-ID: <20190903181853.GA3612@kroah.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1908151047100.1664-100000@iolanthe.rowland.org>
On Thu, Aug 15, 2019 at 10:47:45AM -0400, Alan Stern wrote:
> On Thu, 15 Aug 2019, Greg KH wrote:
>
> > On Thu, Aug 08, 2019 at 02:23:00PM -0400, Alan Stern wrote:
> > > On Thu, 8 Aug 2019, Greg KH wrote:
> > >
> > > > On Thu, Aug 08, 2019 at 01:34:08PM -0400, Alan Stern wrote:
> > > > > The syzbot fuzzer found a lockdep violation in the rio500 driver:
> > > > >
> > > > > ======================================================
> > > > > WARNING: possible circular locking dependency detected
> > > > > 5.3.0-rc2+ #23 Not tainted
> > > > > ------------------------------------------------------
> > > > > syz-executor.2/20386 is trying to acquire lock:
> > > > > 00000000772249c6 (rio500_mutex){+.+.}, at: open_rio+0x16/0xc0
> > > > > drivers/usb/misc/rio500.c:64
> > > > >
> > > > > but task is already holding lock:
> > > > > 00000000d3e8f4b9 (minor_rwsem){++++}, at: usb_open+0x23/0x270
> > > > > drivers/usb/core/file.c:39
> > > > >
> > > > > which lock already depends on the new lock.
> > > > >
> > > > > The problem is that the driver's open_rio() routine is called while
> > > > > the usbcore's minor_rwsem is locked for reading, and it acquires the
> > > > > rio500_mutex; whereas conversely, probe_rio() and disconnect_rio()
> > > > > first acquire the rio500_mutex and then call usb_register_dev() or
> > > > > usb_deregister_dev(), which lock minor_rwsem for writing.
> > > > >
> > > > > The correct ordering of acquisition should be: minor_rwsem first, then
> > > > > rio500_mutex (since the locking in open_rio() cannot be changed).
> > > > > Thus, the probe and disconnect routines should avoid holding
> > > > > rio500_mutex while doing their registration and deregistration.
> > > > >
> > > > > This patch adjusts the code in those two routines to do just that. It
> > > > > also relies on the fact that the probe and disconnect routines are
> > > > > protected by the device mutex, so the initial test of rio->present
> > > > > needs no extra locking.
> > > > >
> > > > > Reported-by: syzbot+7bbcbe9c9ff0cd49592a@syzkaller.appspotmail.com
> > > > > Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
> > > > > Fixes: d710734b0677 ("USB: rio500: simplify locking")
> > > > > CC: Oliver Neukum <oneukum@suse.com>
> > > > > CC: <stable@vger.kernel.org>
> > > > >
> > > > > ---
> > > > >
> > > > > This patch is different from the one I posted earlier. I realized that
> > > > > we don't want to register the device's char file until after the
> > > > > buffers have been allocated.
> > > >
> > > > Should I revert Oliver's patch?
> > >
> > > Sorry, I should have explained more clearly: This goes on top of
> > > Oliver's patch. In fact, Oliver's patch is the one listed in the
> > > Fixes: tag.
> > >
> > > You do not need to apply Oliver's reversion. Assuming he agrees that
> > > this patch is correct, of course.
> >
> > Ok, I applied the revert, and that's in 5.3-rc4. So of course this does
> > not apply :)
> >
> > Shoudl I revert the revert and then apply this? I will if I can get an
> > ack from Oliver...
>
> Either that or else Oliver and I can squash the two patches into one.
I've now merged both, thanks.
greg k-h
next prev parent reply other threads:[~2019-09-03 18:18 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1565187142.15973.3.camel@neukum.org>
2019-08-08 14:33 ` possible deadlock in open_rio Alan Stern
2019-08-08 14:33 ` syzbot
2019-08-08 14:33 ` syzbot
2019-08-08 14:44 ` Andrey Konovalov
2019-08-08 17:34 ` [PATCH] USB: rio500: Fix lockdep violation Alan Stern
2019-08-08 17:58 ` Greg KH
2019-08-08 18:23 ` Alan Stern
2019-08-15 12:48 ` Greg KH
2019-08-15 14:47 ` Alan Stern
2019-09-03 18:18 ` Greg KH [this message]
2019-08-19 11:51 ` Oliver Neukum
2019-08-08 17:43 ` possible deadlock in iowarrior Alan Stern
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=20190903181853.GA3612@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=andreyknvl@google.com \
--cc=linux-usb@vger.kernel.org \
--cc=oneukum@suse.com \
--cc=stern@rowland.harvard.edu \
--cc=syzkaller-bugs@googlegroups.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.