Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp4037184yba; Tue, 9 Apr 2019 09:46:56 -0700 (PDT) X-Google-Smtp-Source: APXvYqyEaDww/WIfg4s8vPIRKN2dNYGIVlimmAGvU9zPxmBlH3a9xkK0iv54xMJQFznzQ/faexqm X-Received: by 2002:a17:902:b686:: with SMTP id c6mr38440874pls.14.1554828416854; Tue, 09 Apr 2019 09:46:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554828416; cv=none; d=google.com; s=arc-20160816; b=y8s9MkLwucnB0eY7dnIWO8a6UNDB748C9l3gB+M9R2hhwhg3DKTSjMkRvxIPil2q1g XA1ek4NZChRfAoX5PvX4/m6+LmPio69KynV7VY27xXQPKSADf1tJbA5Jxi/4TG0X1yW0 yVtRq0SZSi5XUneKI0ui12eGIknJa+JzSNyzT8LFBbNgZXa2Pj2OfM7QdoAbCzJXzGCM 3IGCTWuAZP9EJih/hxmtGiPbN+3g0+QhfHEJ+ZyCmTBnbLpEE+ELYu0CwpsKN/la8RZY POaywiO/aQyAOWl72wxR7cPK/zT9c8U7KlZeEx2RT2FRr38IB0gvo5wruxiSCGtDsFdR HQ5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:in-reply-to :subject:cc:to:from:date; bh=t+SYy4f9RmAZDeu9/NkYqD8woU053EY+uvilfwbrYtg=; b=eetfzzAD7jflrNfCpEK5k4Adqp9qi7DD3ZdWHXByD4Rvjhm44PAvNd509mVtxk/zhl Ugwaesjyx+LDrCYM37jllUTwvCbBEBvk9FQDP67NeFhacrnSRRytn1ucZ5m1XyQQ1WXW wp+WbVMNhFWM+iFpEX7uZy2Rp+UApiAevM+3o/ia76ENXIETHnjiJukvnDY7Y73B0bG/ 8WvousmFvBUBruKXh0rt6oDef7xS/9BN9UnYvunae+Q1vPa9BKJwfkKxrruqezUl+4N1 RfWgY+iAqlHgKwaMrS9FRFMmH2ba1XZG2DNq0L6xM3zZVwnQV8keC2LvQqpBZacoEvL6 rV3w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q78si27641464pgq.321.2019.04.09.09.46.41; Tue, 09 Apr 2019 09:46:56 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726666AbfDIQpz (ORCPT + 99 others); Tue, 9 Apr 2019 12:45:55 -0400 Received: from iolanthe.rowland.org ([192.131.102.54]:46462 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1726570AbfDIQpy (ORCPT ); Tue, 9 Apr 2019 12:45:54 -0400 Received: (qmail 4779 invoked by uid 2102); 9 Apr 2019 12:45:53 -0400 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 9 Apr 2019 12:45:53 -0400 Date: Tue, 9 Apr 2019 12:45:53 -0400 (EDT) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Bart Van Assche cc: "Martin K. Petersen" , , "James E.J. Bottomley" , Oliver Neukum , , USB Storage list , , Kernel development list , SCSI development list , USB list Subject: Re: [PATCH] usb: uas: fix usb subsystem hang after power off hub port In-Reply-To: <1554823007.161891.6.camel@acm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 9 Apr 2019, Bart Van Assche wrote: > 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(). The unbind happens from inside the SCSI EH callback. If that really is not allowed, we'll need to change it. Or we can just change it regardless, since the effort required is pretty small. Kento, please try the patch below. Does it help with your problem? Alan Stern Index: usb-4.x/drivers/usb/core/hub.c =================================================================== --- usb-4.x.orig/drivers/usb/core/hub.c +++ usb-4.x/drivers/usb/core/hub.c @@ -5902,7 +5902,9 @@ int usb_reset_device(struct usb_device * cintf->needs_binding = 1; } } - usb_unbind_and_rebind_marked_interfaces(udev); + /* If the reset failed, hub_wq will unbind drivers later */ + if (ret == 0) + usb_unbind_and_rebind_marked_interfaces(udev); } usb_autosuspend_device(udev);