Hi, On 07/10/2012 05:31 PM, Peter Stuge wrote: > Hey, > > Hans de Goede wrote: >> doing the disarm without the flying-transfers lock held is racy, ie: > > Bringing back the old behavior was a start. Yes, race also. The > attached patch on top of the previous fix avoids the race, and is > available also via > > git fetch git://git.libusb.org/libusb-stuge.git for_libusbx/timerfd_race && \ > git cherry-pick FETCH_HEAD >
Ok, with this patch added I think the end-result is better then Pete's patch + my suggest change to only do the disarm based on a flag. So Pete, if you agree lets go with Peter's 2 patches. > >> the setting of the timerfd from libusb_submit_transfer should >> also be moved to add_to_flying_list() and be done under the >> protected of the flying-transfers lock. > > It makes sense from the point of view of critical sections, but > starting the timer before the transfer has actually been submitted > would mean that the timeout while the transfer is on the bus will > always be shorter than the user-specified timeout, offset by however > long it takes to do the submit itself - while starting the timer > *after* submitting the transfer means that timeout while in flight > will always be ever so slightly longer than the user-specified value. If users set the timeout so close to the actual normal response time of the device they are just asking for trouble, IMHO ensuring that we don't create some kind of possible race here is much more important then the timeout maybe firing a few 100 usecs to early. Moreover as Pete pointed out we calculate the time to set the timerfd to before we do any of this, so this whole argument to not move the setting of the timerfd under the flying-transfers-lock is mute. IOW lets just make the change and move the setting of the timerfd on submit to under the flying-transfers-lock. 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
