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.
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.
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,
/Pete
------------------------------------------------------------------------------
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
