On Fri, Jan 08, 2016 at 03:56:56PM +0000, Dean Jenkins wrote: > Hi, > > Here is a summary of the kernel ticket that I created at > https://bugzilla.kernel.org/show_bug.cgi?id=110531 > > Before kernel 3.13, sysfs read_descriptors() was non-blocking and in kernel > 3.13 the following commit was added > "232275a USB: fix substandard locking for the sysfs files" > which added usb_lock_device(udev) which can cause blocking to > read_descriptors(). > > Blocking occurs when sysfs read_descriptors' udev == hub_event's hdev value. > > If USB comms have failed in hub_port_init() then the blocking can be up to > 30 seconds due to the 6 retry attempts at re-establishing USB comms with a > USB device. > > This period of mutex blocking can be too long for applications as the > application's thread for reading sysfs hangs until usb_unlock_device(hdev) > is called in hub_event(). > > This issue was observed in our embedded ARM based commercial project that > had an application that was reading the descriptors via sysfs to determine > whether the hub and devices supported OTG mode. The system had a check to > see whether the application got to a "normal" system state within 25 seconds > of power-up. > > In the failure scenario, a malfunctioning USB stick was connected (present > at power-up) to the ARM system. The USB stick worked OK for 10 seconds but > failed causing usb_events() (ARM was based on kernel 3.14) to cause > hub_init_port() to attempt up to 6 times to try to re-establish USB > communications, this can take up to 30 seconds to complete all attempts. > > Whilst the connection attempts are being attempted, hub_events() holds a > device lock referenced by hdev. However, sysfs read_descriptors() can be > blocked on this held lock when udev == hdev of hub_events(). When > read_descriptors() is blocked, this blocking can be up to 30 seconds. > > In our project, a blocked read_descriptors() thread causes the sysfs read > thread in the application to hang which prevents the application from > reaching the "normal" state within the 25 second constraint set by the > project and subsequently the management entity triggers a controlled system > reboot. The board cyclically reset as the USB stick failed on each power-up. > For the project, this behaviour is undesirable. I recommend not using USB devices that break :) > Proposal: > ========= > > Remove the usb_lock_device(udev) and usb_unlock_device(udev) from > devices/usb/core/sysfs.c in read_descriptors() that was added by the kernel > 3.13 commit > "232275a USB: fix substandard locking for the sysfs files" > > Any comments to this proposal ? The locking was added because it was needed, we can't just remove it and expect things to work properly, don't you agree? I understand that having a timeout like this is not "nice", but given the issues involved, I think that's the best solution, your system shouldn't reset itself due to an artificial constraint you set on it (the 25 second timeout), when relying on commodity hardware that can easily fail. sorry, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
