On Thu, Jun 05, 2003, Johannes Erdfelt <[EMAIL PROTECTED]> wrote: > Here's a patch to fix a race condition in usbdevfs. The fix is in hub.c > but the race is related to usbdevfs. > > The race goes like this: > > Process 1 (khubd) Process 2 (mount) > usb_hub_port_connect_change() > hub->children[port] = dev > usb_new_device() > usbdevfs_read_super() > recurse_new_dev_inode() > new_dev_inode() > list_add_tail(..., &dev->inodes) > usbdevfs_add_device() > new_dev_inode() > list_add_tail(..., &dev->inodes) > > The problem is that the inode gets added twice, corrupting dev->inodes. > This will cause a problems at disconnect where the same inode will be > freed twice, causing a neverending loop, or an oops. I think it will > also cause problems at unmount. > > The fix is to just move setting hub->children to later in the > enumeration process. This way usbdevfs_read_super won't see the device > before it has been through the usbdevfs_add_device path.
Thinking about it some more, I may have introduced a new race the other way. There's a chance between usbdevfs_add_device and hub->children[port] being set that a new mount can be made. It's definately a lot smaller than before (previously we had quite a few kmallocs and usb_control_msg calls which could cause context switches for many milliseconds) and not as severe (the device just won't show up on the mount instead of a BUG() call or neverending loop). I'll take a deeper look into it, but this patch should atleast be a significant improvement. JE ------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
