Re: kern/46522

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

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