linux-kernel - Re: [PATCH] usb: uas: fix usb subsystem hang after power off hub port

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1554823007.161891.6.camel@acm.org>
Date:   Tue, 09 Apr 2019 08:16:47 -0700
From:   Bart Van Assche <bvanassche@....org>
To:     Alan Stern <stern@...land.harvard.edu>,
        "Martin K. Petersen" <martin.petersen@...cle.com>
Cc:     Kento.A.Kobayashi@...y.com,
        "James E.J. Bottomley" <jejb@...ux.ibm.com>,
        Oliver Neukum <oneukum@...e.com>, gregkh@...uxfoundation.org,
        USB Storage list <usb-storage@...ts.one-eyed-alien.net>,
        Jacky.Cao@...y.com,
        Kernel development list <linux-kernel@...r.kernel.org>,
        SCSI development list <linux-scsi@...r.kernel.org>,
        USB list <linux-usb@...r.kernel.org>
Subject: Re: [PATCH] usb: uas: fix usb subsystem hang after power off hub
 port

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.