On 15 Apr 2014, at 20:18, Taylor R Campbell <campbell+netbsd-source-change...@mumble.net> wrote:
> Date: Tue, 15 Apr 2014 09:50:45 +0000 > From: Juergen Hannken-Illjes <hann...@netbsd.org> > > 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 - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)