Hi,
On 07/12/2012 01:19 AM, Pete Batard wrote:
> On 2012.07.11 10:18, Hans de Goede wrote:
>> 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.
>
> Still on the fence on that one. I'd like to have the second part of the
> equation (moving the setting of the timerfd in flying-transfers-lock as
> well) to get the full picture.
>
> My concern here is that the issue we've been having was apparently due
> to the code having been modified without people realizing they needed to
> be careful about disarming. For that reason alone, I would prefer having
> the disarming encapsulated somewhere where it'll be less prone to mishaps.
>
> Basically, I still think arm_timerfd_for_next_timeout() should be the
> one entity to take care of optionally disarming the timerfd. Else, we
> are moving logic that is better suited to a single timerfd related call
> ("Is there something else to wait for? If yes rearm. If not disarm")
> outside of that call, which is asking for trouble.
I hadn't looked at it that way, but what you're saying makes sense, so
given that I'm fine with either approach.
> Now of course our problem also becomes whether we want to keep the
> timerfd armed while in handle_timerfd_trigger() (which is an option - I
> had an early version of the patch that did just that, and I don't see
> the overhead concerns as that dramatic), and if not, what we are doing
> to make sure that a rearm elsewhere cannot be undone by the
> unconditional disarm we do there, that doesn't care about the flying
> transfer lock.
I believe that all arms / disarm should be done under the
flying transfer lock. Rather then reasoning ourselves a headache about how
it is absolutely safe in all combinations of threads we can come up with to
have an arm / disarm call outside a section holding that lock, lets just
go KISS and always make sure we have the lock and to the necessary checks
on the flying-transfers list before doing the arm/disarm.
> There are elements of handle_timerfd_trigger(), such as just returning
> after an unconditional disarm that fails, that I'm not too fond of, as
> we can very much afford having a failed disarm there and don't actually
> want the timerfd to potentially stay disarmed (in case the call
> half-failed)...
Regards,
Hans
p.s. I'm leaving for a week vacation tomorrow morning, and I won't be
reading email during that time ...
------------------------------------------------------------------------------
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
