Bug 6089

Summary: processes can go in D-state when sg bad happened to USB pluged devices
Product: Drivers Reporter: Thierry Vignaud (thierry.vignaud)
Component: USBAssignee: Greg Kroah-Hartman (greg)
Status: REJECTED INSUFFICIENT_DATA    
Severity: normal CC: bunk, protasnb
Priority: P2    
Hardware: i386   
OS: Linux   
Kernel Version: 2.6.17 Subsystem:
Regression: --- Bisected commit-id:
Bug Depends on:    
Bug Blocks: 5089    
Attachments: trace of a process accessing /proc/bus/usb/devices

Description Thierry Vignaud 2006-02-17 09:20:26 UTC
Most recent kernel where this bug did not occur: 2.6.12  (but nothing related  
has changed in the usb subsystem since)  
Distribution: Mandriva  
Problem Description: 
the kernel offer a view of USB devices  
through /proc/bus/usb/devices. however, the program that read that file can go  
in D state, thus becoming unkillable, if sg bad happens (eg a device that is  
currently used by a process is unplugged). 
 
it's not expected for programs to get freezed and unkillable while reading 
such /proc files. 
  
the kernel should maintain a view of the usb tree so that other processes won't  
becoming iresponsible. this view should be atomically updated when devices are  
(un)plugged.  
  
Steps to reproduce:  
- plug an USB webcam,  
- run xawtv in order to grab video,  
- unplug the webcam
Comment 1 Martin J. Bligh 2006-02-17 09:27:26 UTC
Output of ALT+sysrq+t would probably be useful
Comment 2 Greg Kroah-Hartman 2006-02-17 11:21:42 UTC
Yes, things have changed in the kernel since then.  We should not be accessing
the usb bus anymore when you cat that file (and it's a usbfs file, not a proc
file, usbfs just is mounted in a directory in proc.)

Can you retest with 2.6.15 and let us know if it's still a problem or not?
Comment 3 Greg Kroah-Hartman 2006-03-06 10:33:56 UTC
Closing due to lack of response.

If this is still a problem, please reopen
with the requested information.

Comment 4 Thierry Vignaud 2006-07-27 11:07:37 UTC
This bug is still true as of 2.6.16. Once a webcam is unpluged (here a pwc 
driven one) whereas it's still used by xawtv, then all programs that 
read /proc/bus/usb/devices got stuck on read() and go in D state until xawtv.
Comment 5 Thierry Vignaud 2006-07-27 11:12:42 UTC
s/until./until xawtv is closed./
Comment 6 Greg Kroah-Hartman 2006-07-27 16:09:37 UTC
Can you test 2.6.17?  It's been out for a while now :)
Comment 7 Thierry Vignaud 2006-08-03 04:37:56 UTC
Still valid.  any process opening /proc/bus/usb/devices is blocked in D state 
until the process that was using the unplugged USB device exits.
Comment 8 Greg Kroah-Hartman 2006-08-30 01:17:42 UTC
Can you do a SysRq-T when the processes are stuck so that we can see
where in the kernel they are hanging?  Please attach the output, don't put it
inline.
Comment 9 Thierry Vignaud 2006-09-18 12:44:34 UTC
Created attachment 9047 [details]
trace of a process accessing /proc/bus/usb/devices
Comment 10 Thierry Vignaud 2006-10-03 07:58:05 UTC
There're two bugs here:

- pwc driver should cleanly handle unplug of device
  whether it's in use or not (and return the appropriate
  error code to the processes using it)

- the usb layer should be made more robust against such bugs
  (because obviously one cannot ensure all usb drivers behave
  smoothly on device unplug) maybe by maintaining its own list
  of devices w/o querying the drivers (me not begin a kernel developer,
  my explanation may be wrong

The unplug has be more tough.  The driver has to accept
that the box can be unplugged at any time.
Comment 11 Luc Saillard 2006-10-03 08:44:43 UTC
Did you test with the pwc driver 10.0.x or the one in the kernel (9.xxx) ?

Kernel 2.6.18 has a new pwc driver with some logic change when unplugging the
webcam. I've not test this kernel, but i use 2.6.17+pwc-10.0.12 that can be
found on my website without problem.
Comment 12 Natalie Protasevich 2007-08-11 14:46:12 UTC
Tierry,
Have you had chance to test with recent kernels? Many problems with disconnect and unregister were fixed since then.
Comment 13 Thierry Vignaud 2007-08-13 03:32:47 UTC
I can restest but honestly I fear nothing was changed. I'ven't seen any commit for uncoupling /proc entries (whereas there're some patches for decoupling sysfs which triggered similar bugs (or it looks like))