Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1313269
| From | One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: tty: deadlock between n_tracerouter_receivebuf and flush_to_ldisc |
| Date | 2016-01-20 16:00 +0100 |
| Message-ID | <qT2oO-7Xe-13@gated-at.bofh.it> (permalink) |
| References | (3 earlier) <qRgme-OC-7@gated-at.bofh.it> <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> |
| Organization | Intel Corporation |
> 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.
Alan
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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