Hi Konstantin, On 27/08/15 19:19, Konstantin Belousov wrote: > On Thu, Aug 27, 2015 at 06:28:03PM +0200, Julien Charbon wrote: >> On 27/08/15 12:49, Konstantin Belousov wrote: >>> On Wed, Aug 26, 2015 at 08:14:15PM +0200, Julien Charbon wrote: >>>> As I said, I am not opposed to back out this change, callout(9) API in >>>> mpsafe mode is a already complex/subtle API, it won't change too much >>>> the current complexity. >>>> >>>> Let say that if nobody screams until Friday 8/28, I will put back >>>> r284245 and revert this change _and_ I will make this case clear in the >>>> man page. >>> >>> [Replying to a random message in the whole set of conversations] >>> >>> There is one more case, besides TCP timers, which is equially, of not >>> more, critical and sensitive WRT to the callout_stop(). Look at the >>> sys/kern/subr_sleepqueue.c:sleepq_check_timeout(). Stray return of >>> the false result from callout_stop() causes creation of the non-killable >>> processes: the callout fired, we missed the wakeup and went to sleep >>> by manually doing the context switch. Such thread cannot be woken up. >>> >>> I suspect that your fix is a better approach than my attempt to look >>> at something similar at PR 200992 (may be not). >> >> This change (r286880) won't improve the PR 200992: >> >> r286880 only addresses a case where callout_stop() returns 1 instead of >> 0. Thus the only thing that can do r286880 to PR 200992: >> >> - Don't change anything the issues >> - Worsen the issue >> >> Sorry to kill your hope of a simple and elegant fix for PR 200992. > > Well, not that I am frustrated much. Thank you for taking a look. > Did you read the patch attached to the PR ?
Right, I read it from here: https://bugs.freebsd.org/bugzilla/attachment.cgi?id=157915&action=diff And I am not confident enough to say if it is the right way go. I became knowledgeable on callout calls from TCP timers (D2079 and D2763), but that's it. I would propose rrs (as he introduced the 'not_on_a_list' logic) and jhb for reviewing your patch. And unlike me (D3078), don't underestimate the callout complexity in mpsafe mode. :) -- Julien
signature.asc
Description: OpenPGP digital signature