From: Alan Stern <stern@rowland.harvard.edu>
To: Troels Liebe Bentsen <troels@connectedcars.dk>
Cc: Greg KH <gregkh@linuxfoundation.org>, linux-usb@vger.kernel.org
Subject: Re: All USB tools hang when one descriptor read fails and needs to timeout
Date: Fri, 27 Jan 2023 11:07:18 -0500 [thread overview]
Message-ID: <Y9P2tvPkdwHrbPXd@rowland.harvard.edu> (raw)
In-Reply-To: <CAHHqYPNtVkHoiX1LrxUDa32BgVsgymcPtKVODcVGxEh2f=tYRw@mail.gmail.com>
On Fri, Jan 27, 2023 at 03:12:11PM +0100, Troels Liebe Bentsen wrote:
> On Thu, 26 Jan 2023 at 17:17, Alan Stern <stern@rowland.harvard.edu> wrote:
> >
> > On Thu, Jan 26, 2023 at 02:59:35PM +0100, Troels Liebe Bentsen wrote:
> > > It might be a special use case, for our automated hardware testing station
> > > we know what goes into what port/hub so it would be nice to have an option
> > > to lower the timeout in general or per hub or per port.
> >
> > There already is such an option. It's named "early_stop" and it's
> > described in Documentation/ABI/testing/sysfs-bus-usb. You may not be
> > aware of it because it was added after the 6.1 version of the kernel was
> > released.
>
> Thanks, is it something that has to be enabled when compiling the kernel?
No, it is always enabled.
> Using Ubuntu mainline 6.1.4 and it does not seem to have this file in the
> ports folder.
Probably because it is still quite new.
> > > Ahh, sorry I misunderstood but then it makes even less sense that the hub's
> > > descriptors file blocks when the device hangs or am I missing something.
> >
> > Reading the file blocks because it has to be mutually exclusive with
> > other parts of the kernel which can reallocate the buffers storing the
> > descriptors. This mutual exclusion is provided by a per-device lock,
> > and for hubs this device lock is held while a child device is being
> > probed.
> >
> I guess the reasoning for also holding a lock for the hubs is that there is some
> accounting on the hub for the children. But the hub's descriptors file won't
> change because a child device got enumerated right?
That's true, and in principle a separate lock could be used. But there
never seemed to be any need for adding a second lock. Until now.
> Also if I understand it correctly based on your second email both the parsed
> sysfs files(fx idProduct, idVendor, etc.) and the descriptors file won't change
> for the lifetime of the hub. It's just that the descriptors file is backed by
> buffers that need to be locked because they can be reallocated by the kernel.
The files that export data from the device descriptor (idProduct etc.)
might change during a device's lifetime, but the buffer they read from
won't get reallocated.
However, now that I look more closely I see that the buffers for the
config descriptors won't get reallocated either! Evidently this was
changed back in 2014 by commit e50a322e5177 ("usb: Do not re-read
descriptors for wired devices in usb_authorize_device()"), but nobody
realized at the time that the locking for the descriptors sysfs could
then be relaxed.
> Why not store the descriptors file the same way as the parsed sysfs files,
> etc. it seems fairly small and I guess it contains the same data that is found
> in the sysfs folder for the hub?
The buffer holding the device descriptor is fixed size, since all device
descriptors are always 18 bytes long. The configuration and interface
descriptors are variable length, so their buffers have to be allocated
on-the-fly.
> I don't know how much work it would be to try to avoid locking the hub or if
> it even makes sense. So maybe it would be better if we spent time trying to
> workaround this in userspace, fx. by getting libusb to open the descriptors
> file in non-blocking mode and falling back to reading the individual files in
> sysfs if we get an EAGAIN. Would there be anything wrong with that
> approach?
Now that I know the config descriptors won't get reallocated after all,
I can remove the locking from the descriptors file entirely. A patch to
do this is below. It ought to fix your problem. Try it and see.
> Also in general thanks for the quick and detailed responses, it's a
> pleasure writing on this mailing list.
You're welcome.
Alan Stern
Index: usb-devel/drivers/usb/core/sysfs.c
===================================================================
--- usb-devel.orig/drivers/usb/core/sysfs.c
+++ usb-devel/drivers/usb/core/sysfs.c
@@ -869,11 +869,7 @@ read_descriptors(struct file *filp, stru
size_t srclen, n;
int cfgno;
void *src;
- int retval;
- retval = usb_lock_device_interruptible(udev);
- if (retval < 0)
- return -EINTR;
/* The binary attribute begins with the device descriptor.
* Following that are the raw descriptor entries for all the
* configurations (config plus subsidiary descriptors).
@@ -898,7 +894,6 @@ read_descriptors(struct file *filp, stru
off -= srclen;
}
}
- usb_unlock_device(udev);
return count - nleft;
}
next prev parent reply other threads:[~2023-01-27 16:07 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-26 11:49 All USB tools hang when one descriptor read fails and needs to timeout Troels Liebe Bentsen
2023-01-26 12:23 ` Greg KH
2023-01-26 13:06 ` Troels Liebe Bentsen
2023-01-26 13:12 ` Greg KH
2023-01-26 13:59 ` Troels Liebe Bentsen
2023-01-26 14:27 ` Hans Petter Selasky
2023-01-26 15:26 ` Troels Liebe Bentsen
2023-01-26 16:23 ` Alan Stern
2023-01-26 16:17 ` Alan Stern
2023-01-27 14:12 ` Troels Liebe Bentsen
2023-01-27 16:07 ` Alan Stern [this message]
2023-01-31 15:59 ` Troels Liebe Bentsen
2023-01-31 20:41 ` Alan Stern
2023-01-31 20:56 ` Greg KH
2023-02-07 8:25 ` Troels Liebe Bentsen
2023-02-07 8:33 ` Troels Liebe Bentsen
2023-02-07 17:52 ` Alan Stern
2023-02-08 16:48 ` Alan Stern
2023-02-08 20:46 ` Troels Liebe Bentsen
2023-02-08 21:57 ` Alan Stern
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=Y9P2tvPkdwHrbPXd@rowland.harvard.edu \
--to=stern@rowland.harvard.edu \
--cc=gregkh@linuxfoundation.org \
--cc=linux-usb@vger.kernel.org \
--cc=troels@connectedcars.dk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox