From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Tyler Hall <tylerwhall@gmail.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Nicolai Stange <nicstange@gmail.com>,
Johannes Berg <johannes@sipsolutions.net>,
"Paul E.McKenney" <paulmck@linux.vnet.ibm.com>
Subject: Re: deadlock in debugfs synchronize_srcu() when unplugging USB
Date: Mon, 16 Oct 2017 09:51:03 +0200 [thread overview]
Message-ID: <20171016075103.GC3044@kroah.com> (raw)
In-Reply-To: <CAOjnSCYGprej+vEEsSXwr=wO+eWLe2d6sHQYTpp-DFpQ3pmguw@mail.gmail.com>
On Thu, Oct 12, 2017 at 04:01:48PM -0400, Tyler Hall wrote:
> Hi,
>
> I have a reproducible scenario wherein removing a USB device while
> reading /sys/kernel/debug/usb/devices causes a deadlock. This should
> not be specific to any USB device. Any USB device removal that causes
> a call to debugfs_remove() has inverted lock ordering with respect to
> the read() of debug/usb/devices.
>
> e.g.
> read thread: srcu_read_lock(&debugfs_srcu);
> -- usb unplug --
> remove thread: mutex_lock(&usb_bus_idr_lock);
> remove thread: synchronize_srcu(&debugfs_srcu); <- blocked
> read thread: mutex_lock(&usb_bus_idr_lock); <- blocked
> read thread: srcu_read_unlock(&debugfs_srcu, ...);
>
> This seems to be another flavor of what Johannes Berg reported:
> deadlock in synchronize_srcu() in debugfs?
> https://lkml.org/lkml/2017/3/23/415
>
> I applied this patch set from Nicolai Stange and can no longer
> reproduce the hang.
> [RFC PATCH v2 0/9] debugfs: per-file removal protection
> https://lkml.org/lkml/2017/5/3/292
>
> As patch 2/9 in the series indicates, commit 49d200deaa68 ("debugfs:
> prevent access to removed files' private data") is where this was
> first introduced, and it is reproducible on v4.14-rc4.
>
> How should we move forward with the resolution of this debugfs change?
> It seems to me that the USB locking is reasonable but the debugfs
> global srcu is overly restrictive. This could lead to unexpected lock
> inversion any time a driver shares a mutex between its debugfs read
> and removal paths.
As Paul stated, fixing up the patches and sending them in is the best
solution, can you help out with that?
thanks,
greg k-h
next prev parent reply other threads:[~2017-10-16 7:50 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-12 20:01 deadlock in debugfs synchronize_srcu() when unplugging USB Tyler Hall
2017-10-12 21:04 ` Paul E. McKenney
2017-10-16 7:51 ` Greg Kroah-Hartman [this message]
2017-10-16 8:15 ` Johannes Berg
2017-10-16 8:31 ` Greg Kroah-Hartman
2017-10-16 15:08 ` Tyler Hall
2017-10-30 23:15 ` [PATCH v3 0/8] debugfs: per-file removal protection Nicolai Stange
2017-10-30 23:15 ` [PATCH v3 1/8] debugfs: add support for more elaborate ->d_fsdata Nicolai Stange
2017-10-30 23:15 ` [PATCH v3 2/8] debugfs: implement per-file removal protection Nicolai Stange
2017-10-30 23:15 ` [PATCH v3 3/8] debugfs: debugfs_real_fops(): drop __must_hold sparse annotation Nicolai Stange
2017-10-30 23:15 ` [PATCH v3 4/8] debugfs: convert to debugfs_file_get() and -put() Nicolai Stange
2017-10-30 23:15 ` [PATCH v3 5/8] IB/hfi1: " Nicolai Stange
2017-11-07 14:29 ` Dennis Dalessandro
2017-10-30 23:15 ` [PATCH v3 6/8] debugfs: purge obsolete SRCU based removal protection Nicolai Stange
2017-10-30 23:15 ` [PATCH v3 7/8] debugfs: call debugfs_real_fops() only after debugfs_file_get() Nicolai Stange
2017-10-30 23:15 ` [PATCH v3 8/8] debugfs: defer debugfs_fsdata allocation to first usage Nicolai Stange
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=20171016075103.GC3044@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=johannes@sipsolutions.net \
--cc=linux-kernel@vger.kernel.org \
--cc=nicstange@gmail.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=tylerwhall@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox