Re: kern/53202: Kernel hangs running t_ptrace_wait:resume1 test

[Taylor R Campbell <campbell%mumble.net@localhost>]

The following reply was made to PR kern/53202; it has been noted by GNATS.

From: Taylor R Campbell <campbell%mumble.net@localhost>
To: Andreas Gustafsson <gson%gson.org@localhost>
Cc: gnats-bugs%NetBSD.org@localhost, christos%NetBSD.org@localhost, rmind%NetBSD.org@localhost
Subject: Re: kern/53202: Kernel hangs running t_ptrace_wait:resume1 test
Date: Thu, 26 Apr 2018 16:54:01 +0000

 > Date: Thu, 26 Apr 2018 19:11:33 +0300
 > From: Andreas Gustafsson <gson%gson.org@localhost>
 > 
 > Earlier, you asked:
 > >  Does inserting a call to yield() after lwp_unsleep in sleepq_block
 > >  change anything, if we restore the use of cv_wait_sig in lwp_wait?
 > 
 > Since this seems to be working, do you think it should be committed?
 
 Maybe.  My understanding of the constraints inside the sleepq and
 scheduler logic is limited.
 
 It may be more prudent to find why the change to cv_wait_sig worked
 around whatever the root cause of the problem with Go was, but I don't
 have any brilliant ideas about that.
 
 In particular, it smells like there is a missing wakeup in the lwp
 exit logic, perhaps owing to an obscure case of a signal delivery that
 happens to cause cv_wait_sig to return early.  But exactly where the
 wakeup needs to happen is unclear.  The condition that the relevant
 cv_wait is waiting for in the `exiting' case of lwp_wait is not
 obvious -- there's a whole string of things whose change might trigger
 it.