From: Greg KH <gregkh@linuxfoundation.org>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
Len Brown <len.brown@intel.com>, Pavel Machek <pavel@ucw.cz>,
arnd@arndb.de, linux-kernel@vger.kernel.org,
linux-pm@vger.kernel.org,
Wedson Almeida Filho <wedsonaf@google.com>,
Dmitry Vyukov <dvyukov@google.com>
Subject: Re: [PATCH] char: misc: make misc_open() and misc_register() killable
Date: Wed, 6 Jul 2022 08:34:44 +0200 [thread overview]
Message-ID: <YsUtBERm94k/iZTy@kroah.com> (raw)
In-Reply-To: <7ddb25ff-60e5-75be-8080-2a7465cca68c@I-love.SAKURA.ne.jp>
On Wed, Jul 06, 2022 at 03:21:15PM +0900, Tetsuo Handa wrote:
> On 2022/07/05 23:35, Tetsuo Handa wrote:
> > On 2022/07/05 23:16, Greg KH wrote:
> >> Some device is being probed at the moment, maybe we have a deadlock
> >> somewhere here...
> >
> > Lockdep says __device_attach() from hub_event() was in progress.
> >
> > ----------------------------------------
> > [ 237.376478][ T28] 5 locks held by kworker/1:1/26:
> > [ 237.381526][ T28] #0: ffff888016b92538 ((wq_completion)usb_hub_wq){+.+.}-{0:0}, at: process_one_work+0x87a/0x1610
> > [ 237.392798][ T28] #1: ffffc90000c2fda8 ((work_completion)(&hub->events)){+.+.}-{0:0}, at: process_one_work+0x8ae/0x1610
> > [ 237.406354][ T28] #2: ffff88801f7ee220 (&dev->mutex){....}-{3:3}, at: hub_event+0x1c1/0x4680
> > [ 237.415920][ T28] #3: ffff88801b6c6220 (&dev->mutex){....}-{3:3}, at: __device_attach+0x7a/0x4a0
> > [ 237.426682][ T28] #4: ffff8880216bc1a8 (&dev->mutex){....}-{3:3}, at: __device_attach+0x7a/0x4a0
> > ----------------------------------------
> >
>
> The number returned by atomic_read(&probe_count) matched the number of works for hub_event()
> in usb_hub_wq workqueue. The probe function is called from hub_event(), and
> usb_stor_msg_common() calls wait_for_completion_interruptible_timeout(MAX_SCHEDULE_TIMEOUT)
> via driver's init function.
>
> But if the usb device is unresponsive, wait_for_completion_interruptible_timeout() sleeps
> forever. And in this testcase (which emulates usb devices using /dev/raw-gadget interface),
> the usb device became unresponsive because the process who is responsible with reading/writing
> /dev/raw-gadget interface is blocked at mutex_lock(&misc_mtx) at misc_open(), and results in
> an AB-BA deadlock condition. Making misc_open() killable solved this problem, by allowing
> the opener of /dev/raw-gadget interface to call fput() upon "send SIGKILL after 5 seconds from
> fork()" behavior.
>
> Anyway,
>
> /*
> * Resuming. We may need to wait for the image device to
> * appear.
> */
> wait_for_device_probe();
>
> in snapshot_open() will sleep forever if some device became unresponsive.
>
> How should we fix this problem?
We can decrease the timeout in usb_stor_msg_common(). I imagine that if
that timeout is ever hit in this sequence, then all will recover, right?
Try decreasing it to a sane number and see what happens.
thanks,
greg k-h
next prev parent reply other threads:[~2022-07-06 6:34 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-13 12:38 INFO: task hung in misc_open (4) syzbot
2022-07-04 6:44 ` [PATCH] char: misc: make misc_open() and misc_register() killable Tetsuo Handa
2022-07-04 7:29 ` Greg KH
2022-07-04 10:25 ` Tetsuo Handa
2022-07-04 11:01 ` Greg KH
2022-07-04 12:34 ` Tetsuo Handa
2022-07-04 12:59 ` Wedson Almeida Filho
2022-07-04 13:48 ` Tetsuo Handa
2022-07-04 13:57 ` Wedson Almeida Filho
2022-07-04 14:07 ` Tetsuo Handa
2022-07-04 14:46 ` Wedson Almeida Filho
2022-07-04 14:31 ` Greg KH
2022-07-05 5:21 ` Tetsuo Handa
2022-07-05 5:37 ` Greg KH
[not found] ` <a1fcc07e-51ef-eaad-f14b-33f1263e45ac@I-love.SAKURA.ne.jp>
2022-07-05 7:20 ` Dmitry Vyukov
2022-07-05 10:10 ` Greg Kroah-Hartman
2022-07-08 6:06 ` Dmitry Vyukov
2022-07-05 14:01 ` Tetsuo Handa
2022-07-05 14:16 ` Greg KH
2022-07-05 14:35 ` Tetsuo Handa
2022-07-06 6:21 ` Tetsuo Handa
2022-07-06 6:34 ` Greg KH [this message]
2022-07-06 10:26 ` Tetsuo Handa
2022-07-06 11:04 ` Oliver Neukum
2022-07-07 5:06 ` Tetsuo Handa
2022-07-07 8:04 ` Greg KH
2022-07-08 13:37 ` Greg KH
2022-07-10 2:27 ` Tetsuo Handa
2022-07-06 12:17 ` Oliver Neukum
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=YsUtBERm94k/iZTy@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=arnd@arndb.de \
--cc=dvyukov@google.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=rafael@kernel.org \
--cc=wedsonaf@google.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.