Re: CVS commit: src/sys/kern

["J. Hannken-Illjes" <hannken%eis.cs.tu-bs.de@localhost>]

On 15 Apr 2014, at 20:18, Taylor R Campbell 
<campbell+netbsd-source-changes-d%mumble.net@localhost> wrote:

>   Date: Tue, 15 Apr 2014 09:50:45 +0000
>   From: Juergen Hannken-Illjes <hannken%NetBSD.org@localhost>
> 
>   Fix a deadlock where one thread exits, enters fstrans_lwp_dtor()
>   and wants fstrans_lock.  This thread holds the proc_lock.
> 
> This sounds fishy.  lwp_exit does not hold proc_lock while calling
> lwp_finispecific, so there are no invariants covered by proc_lock that
> the lwp_specific destructors can rely on.  I'm inclined to say that it
> is a bug for exit1 to hold proc_lock when it calls lwp_finispecific
> (and proc_finispecific).  Can we just release it before and re-acquire
> it after calling lwp/proc_finispecific?
> 
>   Another thread holds fstrans_lock and runs pserialize_perform().
>   As the first thread holds the proc_lock, timeouts are blocked and
>   the second thread blocks forever in kpause().
> 
> This also sounds fishy.  How does T1's holding proc_lock cause T2 to
> block forever in kpause?  I think I'm missing something in this
> analysis.  kpause doesn't take proc_lock, does it?

Kpause() registers a callout and sleeps.

On the next clock tick the softclk thread calls timer_intr() which
wants the proc_lock.  Now we successfully stopped all softclk threads.

The callout for kpause() will not fire -> deadlock/

--
J. Hannken-Illjes - hannken%eis.cs.tu-bs.de@localhost - TU Braunschweig 
(Germany)