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

What are the old paths impacted?

Hi Gleb,

Digging through my e-mail archive rephrasing myself and comments about:


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.


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;


freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to