Hi, On 07/30/2012 05:24 PM, Alan Stern wrote: > On Mon, 30 Jul 2012, Peter Stuge wrote: > >> Hans de Goede wrote: >>>> The only way to fix this for certain is to add an atomic >>>> detach-and-claim call to the kernel. I don't know if this is >>>> worth it, though. >>> >>> Having spend some time thinking about this, I believe it is worth >>> it, both to fix this race, as well as to fix the >>> detach-kernel-driver except when it is usbfs race. >> >> I agree. >> >>> For a detach-and-claim ioctl it would make sense to not detach >>> (but still / only claim) if the attached driver (already) is usbfs. >>> Nicely fixing the race there too. >>> >>> So if you're ok with adding such an ioctl I'll write a patch for it. > > Okay, go ahead.
Ok, I'll write a patch for this. >> Consider making the detach-except-when ioctl generic, so that >> userspace can provide any valid driver name, and let NULL mean usbfs. > > No, let NULL mean "always detach". "usbfs" can mean usbfs. :-) Peter is talking about making the detach-and-claim ioctl be, detach-and-claim-except-when driver is passed in driver name. This works fine, but, what if apps want a detach-and-claim-if driver is passed in driver name. This is not as crazy as it sounds, since some apps will know what driver they want to "steal" the device from, and if for some reason any other driver is attached, that would be unexpected and they may not want to continue... So to make this truly generic, we need to add a flag to the ioctl parameters to indicate whether the (optional) driver argument is a detach-except-when, or a detach-if-driver-equals argument. I'll start working on a patch implementing such an ioctl, including such a flag. Regards, Hans ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
