Received: by 2002:a25:5b86:0:0:0:0:0 with SMTP id p128csp1577208ybb; Fri, 29 Mar 2019 07:15:09 -0700 (PDT) X-Google-Smtp-Source: APXvYqxfBXHECvkp8xelPEmwt6YYkJNhYNfpuD+yrrOIBw0xpckPBVkJkABYCZE6ggWcHpP0SLMk X-Received: by 2002:a17:902:be0a:: with SMTP id r10mr35089938pls.4.1553868909849; Fri, 29 Mar 2019 07:15:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553868909; cv=none; d=google.com; s=arc-20160816; b=jcFwjlQZTRPvdhd4c7g/QNohGIW8rFMU861doG5d5TL5LQmEcbqyXNjwwoE6Kt9qj0 I2SIE6RsQ5gyji3566KB9XQWrqYGizpgZQ5YRwX30bSwccYFOsdxn2pNw9B/UWIwn18X GQq7OtNwFIcI+aKfASr6tRoPOfs5loSf4QTopKb4cnlqWpRLTX47M2qBWWmChd/U+VSr uq2V3cegypkugSPc9xGQ+3r83inoOodKCRuec1J/+hzuCeLb58xGwiLAo4vyBOsC6ci2 BAxAoaUJilLTqnpDAHJrqexRtWiUV1M4ZzcvppyfJFuTYBFJstBcfwJG1VPTrAgiiPwr nsXg== 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=RJToqK1pJsd6vAWD9jtLRtG8VICS0Woaw/ESIpom+6c=; b=natVTWlKqB7rDjTLMhqQB6RNhfx8CPvV/BLT2EkrPshMg+DGL1es5j9VOaRmnsUGRU IZaEMqDxc8zIh0P3T0NtxQjJrtzAHNr7+5XERrRlU3NcprInbE0oZyfM0JaxLYwVW0Vo 8Ozg91b2ATOanFS2UvCRyQZ+22RaJvzw5Akcu0dXwTmwWA/ZCAXTMeRNIxmHGH0xb4Mw rLByMb2VmeYHtf7DjMGid4VfRsb0BtJalM8m/Cs6Y2XrXYjpijbYQK8LCKG6ADooz9Mk +a9BJYOGMqJtR46/zEaqvYRW5eiy8v6W6enkYbJ6xfapP7hbzV1wQ3rNfjgprsNFavmJ kUXQ== 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 l16si2035392pgh.509.2019.03.29.07.14.54; Fri, 29 Mar 2019 07:15:09 -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 S1729364AbfC2ON6 (ORCPT + 99 others); Fri, 29 Mar 2019 10:13:58 -0400 Received: from iolanthe.rowland.org ([192.131.102.54]:49076 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1728833AbfC2ON5 (ORCPT ); Fri, 29 Mar 2019 10:13:57 -0400 Received: (qmail 2706 invoked by uid 2102); 29 Mar 2019 10:13:56 -0400 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 29 Mar 2019 10:13:56 -0400 Date: Fri, 29 Mar 2019 10:13:56 -0400 (EDT) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Oliver Neukum cc: gregkh@linuxfoundation.org, , , , , , Subject: Re: [PATCH] usb: uas: fix usb subsystem hang after power off hub port In-Reply-To: <1553791752.6310.2.camel@suse.com> 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 Thu, 28 Mar 2019, Oliver Neukum wrote: > On Do, 2019-03-28 at 11:57 -0400, Alan Stern wrote: > > On Thu, 28 Mar 2019, Oliver Neukum wrote: > > > > > On Do, 2019-03-28 at 07:53 +0000, Kento.A.Kobayashi@sony.com wrote: > > > > Hi, > > > > > > > > > Sorry, > > > > > > > > > > I thought this was clear. Your patch is making the assumption that the reset is triggered by the SCSI layer. You cannot make that assumption, as there is an ioctl for resetting a USB device. > > > > > In case we are getting an error during the reset (our endpoints vanish), the device driver must report that to the USB layer, so the driver will always be disconnected. > > > > > We cannot drop errors. > > > > > > > > > > Regards > > > > > Oliver > > > > > > > > This patch modified uas_post_reset to skip rebind operation to avoid exception while -ENODEV happens not drop error. > > > > If uas_post_reset happens -ENODEV, usb_reset_and_verify_device must happen error. > > > > So,when we use ioctl(USBDEVFS_RESET) to reset device, if usb_reset_and_verify_device happens error, the error will be reported through ioctl return value. > > > > > > OK, It is possible that I am stupid. We must rebind if uas_post_reset() > > > fails. The driver will crash without the endpoints. Can you please > > > explain again in greater detail, what you are trying to achieve? > > > > Actually no, the driver doesn't have to do anything if the post-reset > > method fails. usbcore will take care of rebinding automatically. > > Yes, but the rebinding is not optional. Hence, either the post_reset() > must fail to trigger it, or it will be triggered anyway. > So if the rebinding hangs the machine, I cannot see how alter > changing the return value of uas_post_reset() would help. > > It looks to me like the state transitions of SCSI are too > restrictive. Maybe I don't understand the problem correctly. It sounds like the problem occurs because uas tries to rebind (Where, how, and why does it do this? I don't see anything special in uas_post_reset) using the same scsi_host structure as before instead of creating a new one. Trying to reuse a defunct host is definitely not allowed. But if uas didn't try to do anything special, it would be unbound from the device, causing the scsi_host to be destroyed. Then when usbcore automatically attempted a rebind, uas would create a new scsi_host and the rebind would have a chance to succeed, without hanging anything. If this description is wrong, please explain more fully. Alan Stern