Re: tty: deadlock between n_tracerouter_receivebuf and flush_to_ldisc

From	Dmitry Vyukov <dvyukov@google.com>
Newsgroups	linux.kernel
Subject	Re: tty: deadlock between n_tracerouter_receivebuf and flush_to_ldisc
Date	2016-01-20 16:20 +0100
Message-ID	<qT2Ib-8li-43@gated-at.bofh.it> (permalink)
References	(4 earlier) <qSXp9-4uM-25@gated-at.bofh.it> <qSZqV-5Mi-9@gated-at.bofh.it> <qSZAD-5Pv-15@gated-at.bofh.it> <qSZKj-68m-27@gated-at.bofh.it> <qT2oO-7Xe-13@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

On Wed, Jan 20, 2016 at 3:58 PM, One Thousand Gnomes
<gnomes@lxorguk.ukuu.org.uk> wrote:
>> I read that, I didn't understand it. Which link is wrong and why?
>>
>> > And I don't understand how the following is a deadlock, since there is
>> > no cycle...
>> >
>> >  Possible unsafe locking scenario:
>> >       CPU0                    CPU1
>> >        ----                    ----
>> >   lock(&buf->lock);
>> >                                lock(&o_tty->termios_rwsem/1);
>> >                                lock(&buf->lock);
>> >   lock(routelock);
>>
>> Ignore the stupid picture, it only really works for simple cases.
>
> There are two line disciplines using two different locking orders
>
> The two line disciplines never execute at once. A given tty is either
> using one or the other and there is a clear and correctly locked
> changeover.
>
>
> semantically its something a bit like
>
>
>  foo(x)
>  {
>           if (x == 1) {
>                 lock(A)
>                 lock(B)
>           } else {
>                 lock(B)
>                 lock(A)
>           }
>
>           Do stuff();
>
>           if (x == 1) {
>                 unlock(B)
>                 unlock(A)
>           } else {
>                 unlock(A)
>                 unlock(B)
>           }
> }
>
> with the guarantee made elsewhere that no instances of foo(1) and foo(0)
> are ever executing at the same time.
>
> That's not by dumb design - it's an interesting "nobody ever noticed
> this" turned up by the lock detector between two totaly unrelated bits of
> code.

In out user-space deadlock detector we have an annotation along the
lines of "forget all info this particular mutex" for such cases
(between foo(0) and foo(1)). Is there something similar in lockdep?

Thread

Re: tty: deadlock between n_tracerouter_receivebuf and  flush_to_ldisc One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-01-15 17:40 +0100
  Re: tty: deadlock between n_tracerouter_receivebuf and flush_to_ldisc Dmitry Vyukov <dvyukov@google.com> - 2016-01-15 18:30 +0100
    Re: tty: deadlock between n_tracerouter_receivebuf and flush_to_ldisc Dmitry Vyukov <dvyukov@google.com> - 2016-01-20 10:40 +0100
      Re: tty: deadlock between n_tracerouter_receivebuf and flush_to_ldisc Peter Zijlstra <peterz@infradead.org> - 2016-01-20 12:50 +0100
        Re: tty: deadlock between n_tracerouter_receivebuf and flush_to_ldisc Dmitry Vyukov <dvyukov@google.com> - 2016-01-20 13:00 +0100
          Re: tty: deadlock between n_tracerouter_receivebuf and flush_to_ldisc Peter Zijlstra <peterz@infradead.org> - 2016-01-20 13:10 +0100
            Re: tty: deadlock between n_tracerouter_receivebuf and  flush_to_ldisc One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-01-20 16:00 +0100
              Re: tty: deadlock between n_tracerouter_receivebuf and flush_to_ldisc Dmitry Vyukov <dvyukov@google.com> - 2016-01-20 16:20 +0100
                Re: tty: deadlock between n_tracerouter_receivebuf and flush_to_ldisc Peter Zijlstra <peterz@infradead.org> - 2016-01-20 17:40 +0100
  Re: tty: deadlock between n_tracerouter_receivebuf and  flush_to_ldisc J Freyensee <james_p_freyensee@linux.intel.com> - 2016-01-20 03:10 +0100

csiph-web