[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: MP-safe DAD timer destruction with callout_stop
On Fri, Jan 12, 2018 at 1:33 PM, Christos Zoulas <christos%astron.com@localhost> wrote:
> In article <CAKrYomiYk93wa12jrbr6Yw5BkJ60fcU1BVJj=_ommC=Gb5w-eA%mail.gmail.com@localhost>,
> Ryota Ozaki <ozaki-r%netbsd.org@localhost> wrote:
>>For a certain reason(*), DAD timers are hard to use
>>callout_halt to destroy DAD timer objects. So I was going
>>to fall back to callout_stop (as of NetBSD 7) that is
>>almost safe but still has a possibility of going wrong(**).
>>(*) See the thread starting at
>>Discussing with @riastradh, we found a possible way to
>>make DAD timer destructions MP-safe with callout_stop.
>>This is a PoC patch:
>>The issue of using callout_stop instead of callout_halt is
>>that callout_stop doesn't actually stop the running callout.
>>So we cannot safety free a related data after calling
>>The new approach copes with the issue by delegating the
>>destruction of a callout to callout itself, which allows us
>>to not wait the callout to finish. This can be done thanks
>>to that DAD objects are separated from other data such as
> Even then (with callout_halt) nothing prevents something from
> calling callout_schedule() or callout_reset() again between
> that time and callout_destroy()... I have code that adds another
> flag that stops further callouts from being reschuled. Does this
> help you?
Not quite in this case. The cause of a race condition in this case
is an in-flight callout handler and the new flag probably doesn't
help for the case. And also DADs can prevent extra callout_schedule
and callout_reset by theirselves (by checking the presence of a
target DAD object).
Nonetheless the feature may be useful in general, although I don't
have use cases now.
Main Index |
Thread Index |