[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
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
> proc_lock it would cause it to hang and be unresponsive.
> @@ -2770,9 +2774,11 @@
> if (tp->t_sigcount != 0)
> TAILQ_REMOVE(&tty_sigqueue, tp, t_sigqueue);
> - mutex_exit(&tty_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 Laight: david%l8s.co.uk@localhost
Main Index |
Thread Index |