From: Bart Van Assche <bvanassche@acm.org>
To: Alan Stern <stern@rowland.harvard.edu>,
"Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Kento.A.Kobayashi@sony.com,
"James E.J. Bottomley" <jejb@linux.ibm.com>,
Oliver Neukum <oneukum@suse.com>,
gregkh@linuxfoundation.org,
USB Storage list <usb-storage@lists.one-eyed-alien.net>,
Jacky.Cao@sony.com,
Kernel development list <linux-kernel@vger.kernel.org>,
SCSI development list <linux-scsi@vger.kernel.org>,
USB list <linux-usb@vger.kernel.org>
Subject: Re: [PATCH] usb: uas: fix usb subsystem hang after power off hub port
Date: Tue, 09 Apr 2019 08:16:47 -0700 [thread overview]
Message-ID: <1554823007.161891.6.camel@acm.org> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1904091014570.1599-100000@iolanthe.rowland.org>
On Tue, 2019-04-09 at 10:44 -0400, Alan Stern wrote:
> On Mon, 8 Apr 2019, Martin K. Petersen wrote:
>
> >
> > Alan,
> >
> > > So it looks as though the SCSI subsystem doesn't like to have a reset
> > > handler call scsi_remove_host.
> >
> > Are you talking about a PCI device removal handler or a SCSI error
> > handler?
>
> The context of this discussion is a USB mass-storage device where the
> device's port on its upstream hub has been powered off. The
> powered-off port causes an executing command to time out. As a result
> the SCSI error handler runs and calls the USB reset routine, but the
> reset fails because the kernel is unable to communicate with the device
> through the powered-off port. This causes the USB reset routine to
> unbind the device from its USB driver, which in turn calls
> scsi_remove_host -- while the error handler is still running.
From which context does that unbind happen? From inside a SCSI EH callback
or from the context of a workqueue? I think the former is not allowed but
that the latter is allowed. The SRP initiator driver (ib_srp.c) follows the
latter approach. See also srp_queue_remove_work().
Bart.
WARNING: multiple messages have this Message-ID (diff)
From: Bart Van Assche <bvanassche@acm.org>
To: Alan Stern <stern@rowland.harvard.edu>,
"Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Kento.A.Kobayashi@sony.com,
"James E.J. Bottomley" <jejb@linux.ibm.com>,
Oliver Neukum <oneukum@suse.com>,
gregkh@linuxfoundation.org,
USB Storage list <usb-storage@lists.one-eyed-alien.net>,
Jacky.Cao@sony.com,
Kernel development list <linux-kernel@vger.kernel.org>,
SCSI development list <linux-scsi@vger.kernel.org>,
USB list <linux-usb@vger.kernel.org>
Subject: usb: uas: fix usb subsystem hang after power off hub port
Date: Tue, 09 Apr 2019 08:16:47 -0700 [thread overview]
Message-ID: <1554823007.161891.6.camel@acm.org> (raw)
On Tue, 2019-04-09 at 10:44 -0400, Alan Stern wrote:
> On Mon, 8 Apr 2019, Martin K. Petersen wrote:
>
> >
> > Alan,
> >
> > > So it looks as though the SCSI subsystem doesn't like to have a reset
> > > handler call scsi_remove_host.
> >
> > Are you talking about a PCI device removal handler or a SCSI error
> > handler?
>
> The context of this discussion is a USB mass-storage device where the
> device's port on its upstream hub has been powered off. The
> powered-off port causes an executing command to time out. As a result
> the SCSI error handler runs and calls the USB reset routine, but the
> reset fails because the kernel is unable to communicate with the device
> through the powered-off port. This causes the USB reset routine to
> unbind the device from its USB driver, which in turn calls
> scsi_remove_host -- while the error handler is still running.
From which context does that unbind happen? From inside a SCSI EH callback
or from the context of a workqueue? I think the former is not allowed but
that the latter is allowed. The SRP initiator driver (ib_srp.c) follows the
latter approach. See also srp_queue_remove_work().
Bart.
WARNING: multiple messages have this Message-ID (diff)
From: Bart Van Assche <bvanassche@acm.org>
To: Alan Stern <stern@rowland.harvard.edu>,
"Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Kento.A.Kobayashi@sony.com,
"James E.J. Bottomley" <jejb@linux.ibm.com>,
Oliver Neukum <oneukum@suse.com>,
gregkh@linuxfoundation.org,
USB Storage list <usb-storage@lists.one-eyed-alien.net>,
Jacky.Cao@sony.com,
Kernel development list <linux-kernel@vger.kernel.org>,
SCSI development list <linux-scsi@vger.kernel.org>,
USB list <linux-usb@vger.kernel.org>
Subject: Re: [PATCH] usb: uas: fix usb subsystem hang after power off hub port
Date: Tue, 09 Apr 2019 08:16:47 -0700 [thread overview]
Message-ID: <1554823007.161891.6.camel@acm.org> (raw)
Message-ID: <20190409151647.NcpQHd-4S3ztFXsX_x2VWeIT_w9pfmiS5VeV448g9p4@z> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1904091014570.1599-100000@iolanthe.rowland.org>
On Tue, 2019-04-09 at 10:44 -0400, Alan Stern wrote:
+AD4 On Mon, 8 Apr 2019, Martin K. Petersen wrote:
+AD4
+AD4 +AD4
+AD4 +AD4 Alan,
+AD4 +AD4
+AD4 +AD4 +AD4 So it looks as though the SCSI subsystem doesn't like to have a reset
+AD4 +AD4 +AD4 handler call scsi+AF8-remove+AF8-host.
+AD4 +AD4
+AD4 +AD4 Are you talking about a PCI device removal handler or a SCSI error
+AD4 +AD4 handler?
+AD4
+AD4 The context of this discussion is a USB mass-storage device where the
+AD4 device's port on its upstream hub has been powered off. The
+AD4 powered-off port causes an executing command to time out. As a result
+AD4 the SCSI error handler runs and calls the USB reset routine, but the
+AD4 reset fails because the kernel is unable to communicate with the device
+AD4 through the powered-off port. This causes the USB reset routine to
+AD4 unbind the device from its USB driver, which in turn calls
+AD4 scsi+AF8-remove+AF8-host -- while the error handler is still running.
From which context does that unbind happen? From inside a SCSI EH callback
or from the context of a workqueue? I think the former is not allowed but
that the latter is allowed. The SRP initiator driver (ib+AF8-srp.c) follows the
latter approach. See also srp+AF8-queue+AF8-remove+AF8-work().
Bart.
WARNING: multiple messages have this Message-ID (diff)
From: Bart Van Assche <bvanassche@acm.org>
To: Alan Stern <stern@rowland.harvard.edu>,
"Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Kento.A.Kobayashi@sony.com,
"James E.J. Bottomley" <jejb@linux.ibm.com>,
Oliver Neukum <oneukum@suse.com>,
gregkh@linuxfoundation.org,
USB Storage list <usb-storage@lists.one-eyed-alien.net>,
Jacky.Cao@sony.com,
Kernel development list <linux-kernel@vger.kernel.org>,
SCSI development list <linux-scsi@vger.kernel.org>,
USB list <linux-usb@vger.kernel.org>
Subject: Re: [PATCH] usb: uas: fix usb subsystem hang after power off hub port
Date: Tue, 09 Apr 2019 08:16:47 -0700 [thread overview]
Message-ID: <1554823007.161891.6.camel@acm.org> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1904091014570.1599-100000@iolanthe.rowland.org>
On Tue, 2019-04-09 at 10:44 -0400, Alan Stern wrote:
> On Mon, 8 Apr 2019, Martin K. Petersen wrote:
>
> >
> > Alan,
> >
> > > So it looks as though the SCSI subsystem doesn't like to have a reset
> > > handler call scsi_remove_host.
> >
> > Are you talking about a PCI device removal handler or a SCSI error
> > handler?
>
> The context of this discussion is a USB mass-storage device where the
> device's port on its upstream hub has been powered off. The
> powered-off port causes an executing command to time out. As a result
> the SCSI error handler runs and calls the USB reset routine, but the
> reset fails because the kernel is unable to communicate with the device
> through the powered-off port. This causes the USB reset routine to
> unbind the device from its USB driver, which in turn calls
> scsi_remove_host -- while the error handler is still running.
>From which context does that unbind happen? From inside a SCSI EH callback
or from the context of a workqueue? I think the former is not allowed but
that the latter is allowed. The SRP initiator driver (ib_srp.c) follows the
latter approach. See also srp_queue_remove_work().
Bart.
next prev parent reply other threads:[~2019-04-09 15:16 UTC|newest]
Thread overview: 82+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-08 9:13 [PATCH] usb: uas: fix usb subsystem hang after power off hub port Kento.A.Kobayashi
2019-03-08 9:13 ` Kento.A.Kobayashi
2019-03-08 9:13 ` Kento.A.Kobayashi
2019-03-08 16:52 ` [PATCH] " Oliver Neukum
2019-03-08 16:52 ` Oliver Neukum
2019-03-08 17:33 ` [PATCH] " Alan Stern
2019-03-08 17:33 ` Alan Stern
2019-03-08 17:33 ` Alan Stern
2019-03-11 8:36 ` [PATCH] " Kento.A.Kobayashi
2019-03-11 8:36 ` Kento.A.Kobayashi
2019-03-11 8:36 ` Kento.A.Kobayashi
2019-03-12 15:37 ` [PATCH] " Oliver Neukum
2019-03-12 15:37 ` Oliver Neukum
2019-03-15 2:28 ` [PATCH] " Kento.A.Kobayashi
2019-03-15 2:28 ` Kento.A.Kobayashi
2019-03-15 2:28 ` Kento.A.Kobayashi
2019-03-25 10:21 ` [PATCH] " Kento.A.Kobayashi
2019-03-25 10:21 ` Kento.A.Kobayashi
2019-03-25 10:21 ` Kento.A.Kobayashi
2019-03-25 10:34 ` [PATCH] " Oliver Neukum
2019-03-25 10:34 ` Oliver Neukum
2019-03-28 7:53 ` [PATCH] " Kento.A.Kobayashi
2019-03-28 7:53 ` Kento.A.Kobayashi
2019-03-28 7:53 ` Kento.A.Kobayashi
2019-03-28 15:15 ` [PATCH] " Oliver Neukum
2019-03-28 15:15 ` Oliver Neukum
2019-03-28 15:57 ` [PATCH] " Alan Stern
2019-03-28 15:57 ` Alan Stern
2019-03-28 15:57 ` Alan Stern
2019-03-28 16:49 ` [PATCH] " Oliver Neukum
2019-03-28 16:49 ` Oliver Neukum
2019-03-29 14:13 ` [PATCH] " Alan Stern
2019-03-29 14:13 ` Alan Stern
2019-03-29 14:13 ` Alan Stern
2019-04-02 0:28 ` [PATCH] " Kento.A.Kobayashi
2019-04-02 0:28 ` Kento.A.Kobayashi
2019-04-02 0:28 ` Kento.A.Kobayashi
2019-04-02 14:38 ` [PATCH] " Alan Stern
2019-04-02 14:38 ` Alan Stern
2019-04-02 14:38 ` Alan Stern
2019-04-04 3:57 ` [PATCH] " Kento.A.Kobayashi
2019-04-04 3:57 ` Kento.A.Kobayashi
2019-04-04 3:57 ` Kento.A.Kobayashi
2019-04-04 19:33 ` [PATCH] " Alan Stern
2019-04-04 19:33 ` Alan Stern
2019-04-04 19:33 ` Alan Stern
2019-04-09 0:28 ` [PATCH] " Kento.A.Kobayashi
2019-04-09 0:28 ` Kento.A.Kobayashi
2019-04-09 0:28 ` Kento.A.Kobayashi
2019-04-09 1:21 ` [PATCH] " Alan Stern
2019-04-09 1:21 ` Alan Stern
2019-04-09 1:21 ` Alan Stern
2019-04-09 2:10 ` [PATCH] " Martin K. Petersen
2019-04-09 2:10 ` Martin K. Petersen
2019-04-09 2:10 ` Martin K. Petersen
2019-04-09 14:44 ` [PATCH] " Alan Stern
2019-04-09 14:44 ` Alan Stern
2019-04-09 14:44 ` Alan Stern
2019-04-09 15:16 ` Bart Van Assche [this message]
2019-04-09 15:16 ` [PATCH] " Bart Van Assche
2019-04-09 15:16 ` Bart Van Assche
2019-04-09 15:16 ` Bart Van Assche
2019-04-09 16:45 ` [PATCH] " Alan Stern
2019-04-09 16:45 ` Alan Stern
2019-04-09 16:45 ` Alan Stern
2019-04-15 0:27 ` [PATCH] " Kento.A.Kobayashi
2019-04-15 0:27 ` Kento.A.Kobayashi
2019-04-15 0:27 ` Kento.A.Kobayashi
2019-04-15 15:18 ` [PATCH] " Alan Stern
2019-04-15 15:18 ` Alan Stern
2019-04-15 15:18 ` Alan Stern
2019-04-15 15:32 ` [PATCH] " Alan Stern
2019-04-15 15:32 ` Alan Stern
2019-04-15 15:32 ` Alan Stern
2019-04-16 2:31 ` [PATCH] " Kento.A.Kobayashi
2019-04-16 2:31 ` Kento.A.Kobayashi
2019-04-16 2:31 ` Kento.A.Kobayashi
2019-04-10 2:11 ` [PATCH] " Martin K. Petersen
2019-04-10 2:11 ` Martin K. Petersen
[not found] <16EA1F625E922C43B00B9D8225022050086961B5@APYOKXMS108.ap.sony.com>
2019-03-04 6:23 ` [PATCH] " Greg KH
2019-03-04 7:19 ` Jacky.Cao
2019-03-04 7:19 ` Jacky.Cao
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=1554823007.161891.6.camel@acm.org \
--to=bvanassche@acm.org \
--cc=Jacky.Cao@sony.com \
--cc=Kento.A.Kobayashi@sony.com \
--cc=gregkh@linuxfoundation.org \
--cc=jejb@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=oneukum@suse.com \
--cc=stern@rowland.harvard.edu \
--cc=usb-storage@lists.one-eyed-alien.net \
/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.