On Fri, Jan 29, 2016 at 12:55:11PM +0300, Vladimir Davydov wrote:
> On Thu, Jan 28, 2016 at 06:30:58PM +0300, Cyrill Gorcunov wrote:
>
> > @@ -679,16 +679,13 @@ void tty_ldisc_hangup(struct tty_struct
> > wake_up_interruptible_poll(&tty->write_wait, POLLOUT);
> > wake_up_interruptible_poll(&tty->read_wait, POLLIN);
> >
> > - tty_unlock(tty);
> > -
> > /*
> > * Shutdown the current line discipline, and reset it to
> > * N_TTY if need be.
> > *
> > * Avoid racing set_ldisc or tty_ldisc_release
> > */
> > - tty_ldisc_lock_pair(tty, tty->link);
> > - tty_lock(tty);
> > + tty_ldisc_lock(tty, MAX_SCHEDULE_TIMEOUT);
>
> Before this patch tty_lock nested into tty_ldisc_lock, not it's
> vice-versa in this function, but e.g. tty_set_ldisc still follows the
> former locking order. Can't it result in a deadlock or, at least,
> lockdep complains?
Nope, as far as I can tell. Previously we've the following
tty_lock -> tty_unlock-> tty_ldisc_lock_pair
which was needed for tty_ldisc_release. And such locking
end up in hanging task when one peer is closed but other
waiting for input. It was reworked in vanilla kernel so
tty_lock/unlock no longer used. I made the same because
it's enough I think. Note I dropped tty_lock/unlock
from _both_ tty_ldisc_hangup and ldisk release.
I run the tests and run container manually with all debug
turned on and I think we're safe. But lets continue testing.
Cyrill
_______________________________________________
Devel mailing list
[email protected]
https://lists.openvz.org/mailman/listinfo/devel
