svn commit: r286880 - head/sys/kern

[Konstantin Belousov]

On Thu, Aug 27, 2015 at 06:28:03PM +0200, Julien Charbon wrote:
> 
>  Hi Konstantin,
> 
> 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 ?