I foresee races between set_bConfigurationValue() and disconnect. But that's not something I can fix in two minutes.
Could you elaborate? I don't think I added any new races there.
Maybe not, but perhaps you exacerbated an existing race. I'm not sure; I haven't examined the code interactions in detail.
This is a problem generic to sysfs attribute files: They can persist and be writeable long after you want them to go away. If a user process has an attribute file open, then calling device_remove_file() won't prevent the show() and store() routines from being invoked. (I have a patch for sysfs that would prevent that, but nobody seems interested in it.) If someone tries to write the config value for a usb_device after it has disconnected and much of its state has gone away, what will happen?
Both usb_set_configuration() and usb_disconnect() are going to want to call usb_disable_device() to shut down all pending operations before they do the next step.
I suppose usb_disconnect() might want to consider grabbing dev->serialize, and usb_set_configuration() might want an _explicit_ check for whether the device is actually connected before it proceeds...
- Dave
------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
