All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alan Stern <stern@rowland.harvard.edu>
To: Oliver Neukum <oneukum@suse.com>
Cc: gregkh@linuxfoundation.org,
	<usb-storage@lists.one-eyed-alien.net>, <Jacky.Cao@sony.com>,
	<Kento.A.Kobayashi@sony.com>, <linux-kernel@vger.kernel.org>,
	<linux-scsi@vger.kernel.org>, <linux-usb@vger.kernel.org>
Subject: Re: [PATCH] usb: uas: fix usb subsystem hang after power off hub port
Date: Fri, 29 Mar 2019 10:13:56 -0400 (EDT)	[thread overview]
Message-ID: <Pine.LNX.4.44L0.1903291007150.1497-100000@iolanthe.rowland.org> (raw)
In-Reply-To: <1553791752.6310.2.camel@suse.com>

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


WARNING: multiple messages have this Message-ID (diff)
From: Alan Stern <stern@rowland.harvard.edu>
To: Oliver Neukum <oneukum@suse.com>
Cc: gregkh@linuxfoundation.org, usb-storage@lists.one-eyed-alien.net,
	Jacky.Cao@sony.com, Kento.A.Kobayashi@sony.com,
	linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org,
	linux-usb@vger.kernel.org
Subject: usb: uas: fix usb subsystem hang after power off hub port
Date: Fri, 29 Mar 2019 10:13:56 -0400 (EDT)	[thread overview]
Message-ID: <Pine.LNX.4.44L0.1903291007150.1497-100000@iolanthe.rowland.org> (raw)

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

WARNING: multiple messages have this Message-ID (diff)
From: Alan Stern <stern@rowland.harvard.edu>
To: Oliver Neukum <oneukum@suse.com>
Cc: gregkh@linuxfoundation.org, usb-storage@lists.one-eyed-alien.net,
	Jacky.Cao@sony.com, Kento.A.Kobayashi@sony.com,
	linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org,
	linux-usb@vger.kernel.org
Subject: Re: [PATCH] usb: uas: fix usb subsystem hang after power off hub port
Date: Fri, 29 Mar 2019 10:13:56 -0400 (EDT)	[thread overview]
Message-ID: <Pine.LNX.4.44L0.1903291007150.1497-100000@iolanthe.rowland.org> (raw)
In-Reply-To: <1553791752.6310.2.camel@suse.com>

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

  reply	other threads:[~2019-03-29 14:13 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                     ` Alan Stern [this message]
2019-03-29 14:13                       ` [PATCH] " 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                             ` [PATCH] " Bart Van Assche
2019-04-09 15:16                               ` 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=Pine.LNX.4.44L0.1903291007150.1497-100000@iolanthe.rowland.org \
    --to=stern@rowland.harvard.edu \
    --cc=Jacky.Cao@sony.com \
    --cc=Kento.A.Kobayashi@sony.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=oneukum@suse.com \
    --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.