Re: panic with tcp timers

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