diff for duplicates of <1554823007.161891.6.camel@acm.org> diff --git a/a/1.txt b/N1/1.txt index 369b51e..bd83140 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -19,7 +19,7 @@ On Tue, 2019-04-09 at 10:44 -0400, Alan Stern wrote: > 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 +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(). diff --git a/a/content_digest b/N1/content_digest index b21205d..0f430eb 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,6 +1,5 @@ - "ref\0Pine.LNX.4.44L0.1904091014570.1599-100000@iolanthe.rowland.org\0" "From\0Bart Van Assche <bvanassche@acm.org>\0" - "Subject\0Re: [PATCH] usb: uas: fix usb subsystem hang after power off hub port\0" + "Subject\0usb: uas: fix usb subsystem hang after power off hub port\0" "Date\0Tue, 09 Apr 2019 08:16:47 -0700\0" "To\0Alan Stern <stern@rowland.harvard.edu>" " Martin K. Petersen <martin.petersen@oracle.com>\0" @@ -36,11 +35,11 @@ "> unbind the device from its USB driver, which in turn calls\n" "> scsi_remove_host -- while the error handler is still running.\n" "\n" - ">From which context does that unbind happen? From inside a SCSI EH callback\n" + "From which context does that unbind happen? From inside a SCSI EH callback\n" "or from the context of a workqueue? I think the former is not allowed but\n" "that the latter is allowed. The SRP initiator driver (ib_srp.c) follows the\n" "latter approach. See also srp_queue_remove_work().\n" "\n" Bart. -0d743a9796e5ee7fb372b616bd00524d18555625a5b3b17f7b1aae2963043efb +e70102b29945bcb4823f3b931f979dc61a1a643f8ef2883e5f871c6192534aa5
diff --git a/a/1.txt b/N2/1.txt index 369b51e..c55a3eb 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -1,27 +1,27 @@ 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. ++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 +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(). +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. diff --git a/a/content_digest b/N2/content_digest index b21205d..6feb0c7 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -16,31 +16,31 @@ "\00:1\0" "b\0" "On Tue, 2019-04-09 at 10:44 -0400, Alan Stern wrote:\n" - "> On Mon, 8 Apr 2019, Martin K. Petersen wrote:\n" - "> \n" - "> > \n" - "> > Alan,\n" - "> > \n" - "> > > So it looks as though the SCSI subsystem doesn't like to have a reset \n" - "> > > handler call scsi_remove_host.\n" - "> > \n" - "> > Are you talking about a PCI device removal handler or a SCSI error\n" - "> > handler?\n" - "> \n" - "> The context of this discussion is a USB mass-storage device where the\n" - "> device's port on its upstream hub has been powered off. The\n" - "> powered-off port causes an executing command to time out. As a result\n" - "> the SCSI error handler runs and calls the USB reset routine, but the\n" - "> reset fails because the kernel is unable to communicate with the device\n" - "> through the powered-off port. This causes the USB reset routine to\n" - "> unbind the device from its USB driver, which in turn calls\n" - "> scsi_remove_host -- while the error handler is still running.\n" + "+AD4 On Mon, 8 Apr 2019, Martin K. Petersen wrote:\n" + "+AD4 \n" + "+AD4 +AD4 \n" + "+AD4 +AD4 Alan,\n" + "+AD4 +AD4 \n" + "+AD4 +AD4 +AD4 So it looks as though the SCSI subsystem doesn't like to have a reset \n" + "+AD4 +AD4 +AD4 handler call scsi+AF8-remove+AF8-host.\n" + "+AD4 +AD4 \n" + "+AD4 +AD4 Are you talking about a PCI device removal handler or a SCSI error\n" + "+AD4 +AD4 handler?\n" + "+AD4 \n" + "+AD4 The context of this discussion is a USB mass-storage device where the\n" + "+AD4 device's port on its upstream hub has been powered off. The\n" + "+AD4 powered-off port causes an executing command to time out. As a result\n" + "+AD4 the SCSI error handler runs and calls the USB reset routine, but the\n" + "+AD4 reset fails because the kernel is unable to communicate with the device\n" + "+AD4 through the powered-off port. This causes the USB reset routine to\n" + "+AD4 unbind the device from its USB driver, which in turn calls\n" + "+AD4 scsi+AF8-remove+AF8-host -- while the error handler is still running.\n" "\n" - ">From which context does that unbind happen? From inside a SCSI EH callback\n" + "From which context does that unbind happen? From inside a SCSI EH callback\n" "or from the context of a workqueue? I think the former is not allowed but\n" - "that the latter is allowed. The SRP initiator driver (ib_srp.c) follows the\n" - "latter approach. See also srp_queue_remove_work().\n" + "that the latter is allowed. The SRP initiator driver (ib+AF8-srp.c) follows the\n" + "latter approach. See also srp+AF8-queue+AF8-remove+AF8-work().\n" "\n" Bart. -0d743a9796e5ee7fb372b616bd00524d18555625a5b3b17f7b1aae2963043efb +4212e376143ac2e3dcd7fd4322610693134b3c78365fd6a99b95f2b4c7f754bb
diff --git a/a/1.txt b/N3/1.txt index 369b51e..bd83140 100644 --- a/a/1.txt +++ b/N3/1.txt @@ -19,7 +19,7 @@ On Tue, 2019-04-09 at 10:44 -0400, Alan Stern wrote: > 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 +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(). diff --git a/a/content_digest b/N3/content_digest index b21205d..f53985d 100644 --- a/a/content_digest +++ b/N3/content_digest @@ -36,11 +36,11 @@ "> unbind the device from its USB driver, which in turn calls\n" "> scsi_remove_host -- while the error handler is still running.\n" "\n" - ">From which context does that unbind happen? From inside a SCSI EH callback\n" + "From which context does that unbind happen? From inside a SCSI EH callback\n" "or from the context of a workqueue? I think the former is not allowed but\n" "that the latter is allowed. The SRP initiator driver (ib_srp.c) follows the\n" "latter approach. See also srp_queue_remove_work().\n" "\n" Bart. -0d743a9796e5ee7fb372b616bd00524d18555625a5b3b17f7b1aae2963043efb +02026112ed3726045e60d144ef9d5679f3a83cf819894ad5bf7f8c70f878726b
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.