On 06/20/16 11:58, Gleb Smirnoff wrote:
J> callout_stop() should return 0 when the callout is currently being
J> serviced and indeed unstoppable
J>
https://reviews.freebsd.org/differential/changeset/?ref=62513&whitespace=ignore-most
What are the old paths impacted?
Hi Gleb,
Digging through my e-mail archive rephrasing myself and comments about:
https://reviews.freebsd.org/D3078
There are two kinds of callouts. So-called MPSAFE callouts which doesn't
have a mutex associated with it, and non-MPSAFE which do.
When you are associating a mutex with a callout, callout_stop() will
_always_ cancel the callback even if it is pending, and this should be
reflected by the return value. Your proposed changes will break that ???
The changes in D3078 didn't take into account "use_lock" at least, and
so the return values for the non-MPSAFE case becomes incorrect.
Hi,
I think this patch is incomplete and can break the return value for non-MPSAFE callouts.
I think the correct statement should check the value of "use_lock" too:
not_running = !(cc_exec_curr(cc, direct) == c && use_lock == 0);
Because if the callback process waits for lock "c_lock" in the callback process then we
have above "cc_exec_curr(cc, direct) == c" is satisfied too, and non-MPSAFE callouts are
always cancelable, via cc_exec_cancel(cc, direct) = true;
--HPS
_______________________________________________
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
