Re: [Libusbx-devel] [PATCH] Fix unconditional disarming of timerfd

2012-08-04 Thread Hans de Goede
Hi, On 08/03/2012 02:46 PM, Pete Batard wrote: Attached is my final proposal then. Looks good, ack. Note I did find one more issue wrt to timer handling, but that is unrelated (and in another part of the code), so lets just push this patch and then fix that issue with a separate patch. See my

Re: [Libusbx-devel] [PATCH] Fix unconditional disarming of timerfd

2012-08-04 Thread Hans de Goede
Hi, On 08/04/2012 10:59 AM, Hans de Goede wrote: Hi, On 08/03/2012 02:46 PM, Pete Batard wrote: Attached is my final proposal then. Looks good, ack. Correction, you forgot to add the arm_timerfd_for_next_timeout() call we agreed would be added to the transfer submission failure path in

Re: [Libusbx-devel] [PATCH] Fix unconditional disarming of timerfd

2012-08-04 Thread Hans de Goede
Hi, On 08/04/2012 10:59 AM, Hans de Goede wrote: Note I did find one more issue wrt to timer handling, but that is unrelated (and in another part of the code), so lets just push this patch and then fix that issue with a separate patch. See my next mail on that. Scrap that, upon typing a

Re: [Libusbx-devel] [PATCH] Fix unconditional disarming of timerfd

2012-08-04 Thread Pete Batard
On 2012.08.04 10:19, Hans de Goede wrote: Correction, you forgot to add the arm_timerfd_for_next_timeout() call we agreed would be added to the transfer submission failure path Forgot about that one - Thanks for spotting it. I have now modified the patch to include this change and pushed it to

Re: [Libusbx-devel] [PATCH] Fix unconditional disarming of timerfd

2012-08-03 Thread Hans de Goede
Hi, On 08/02/2012 01:28 AM, Pete Batard wrote: On 2012.08.01 12:52, Hans de Goede wrote: Hmm, I hadn't noticed the explicit disarm there, since the handle_timeouts_locked code just cancels transfers and does not do anything io-intensive, the run-time for handle_timeouts_locked will be

Re: [Libusbx-devel] [PATCH] Fix unconditional disarming of timerfd

2012-08-01 Thread Pete Batard
On 2012.08.01 12:52, Hans de Goede wrote: Hmm, I hadn't noticed the explicit disarm there, since the handle_timeouts_locked code just cancels transfers and does not do anything io-intensive, the run-time for handle_timeouts_locked will be short, so I see no value in the disarm there, and vote

Re: [Libusbx-devel] [PATCH] Fix unconditional disarming of timerfd

2012-07-12 Thread Pete Batard
On 2012.07.12 22:00, Hans de Goede wrote: I believe that all arms / disarm should be done under the flying transfer lock. Same here. And my concern is that the disarm we do in handle_timerfd_trigger() isn't. Rather then reasoning ourselves a headache about how it is absolutely safe in all

Re: [Libusbx-devel] [PATCH] Fix unconditional disarming of timerfd

2012-07-10 Thread Peter Stuge
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