Re: kern/46522

[David Laight <david%l8s.co.uk@localhost>]

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

From: David Laight <david%l8s.co.uk@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: kern-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
        netbsd-bugs%netbsd.org@localhost, nathanialsloss%yahoo.com.au@localhost
Subject: Re: kern/46522
Date: Mon, 4 Jun 2012 10:06:18 +0100

 On Mon, Jun 04, 2012 at 02:40:05AM +0000, Nat Sloss wrote:
 >  
 >  I have a marginally better patch as it was a bad idea to sleep whilst 
 > holding 
 >  proc_lock it would cause it to hang and be unresponsive.
 ...
 >  @@ -2770,9 +2774,11 @@
 >                  sigemptyset(&tp->t_sigs[i]);
 >          if (tp->t_sigcount != 0)
 >                  TAILQ_REMOVE(&tty_sigqueue, tp, t_sigqueue);
 >  -       mutex_exit(&tty_lock);
 >          mutex_exit(proc_lock);
 >  
 >  +       ttysleep(tp, &tp->t_rawcv, true, mstohz(200));
 >  +       mutex_exit(&tty_lock);
 >  +
 
 While adding a fixed sleep is enough to show where the problem
 lies, it isn't an appropriate solution to the problem.
 
 You need to properly wait for the close to release a reference
 count on the resource, and then free the relevant data areas.
 
 The scheduler can always decide to not run the process you
 are waiting for - so the sleep has to be indefinitely long.
 
 I;m not saying a real fix is easy! the tty subsystem is full
 of places where it isn't remotely MP-safe.
 
        David
 
 -- 
 David Laight: david%l8s.co.uk@localhost