From: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
To: Mike Galbraith <efault@gmx.de>
Cc: Vegard Nossum <vegard.nossum@oracle.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Dave Jones <davej@codemonkey.org.uk>,
Linux Kernel <linux-kernel@vger.kernel.org>,
Jiri Slaby <jslaby@suse.com>
Subject: Re: [bisected] Re: tty lockdep trace
Date: Mon, 5 Jun 2017 16:09:12 +0100 [thread overview]
Message-ID: <20170605160912.56c76d68@lxorguk.ukuu.org.uk> (raw)
In-Reply-To: <1496576071.6573.13.camel@gmx.de>
On Sun, 04 Jun 2017 13:34:31 +0200
Mike Galbraith <efault@gmx.de> wrote:
> On Sun, 2017-06-04 at 12:00 +0200, Vegard Nossum wrote:
> >
> > I don't know how you did it, but this passes my testing (reproducers for
> > both the original issue and the lockdep splat/hang).
>
> I suppose I can sign it off, see if that inspires anyone to come up
> with something better.
>
> drivers/tty: Fix 925bb1ce47f4 circular locking dependency
This is still completely broken and has the same underlying flaw as the
original.
The tty->atomic_write_lock is solely meant to enforce the ordering of a
write() syscall. It can be held for an indefinite amount of time (it's
sometimes multiple seconds in normal flow). Your patch effectively breaks
full duplex support on the serial layer because the internal buffering is
designed to cope with tens of millisecond delays. If the receiver is
multithreaded as is normal then it's also going to wreck the throughput.
We can't defer receive processing indefintiely for transmit processing,
that isn't how RS232 works. If it needs a spinlock putting back to
protect those tty fields then so be it.
NAK
Alan
next prev parent reply other threads:[~2017-06-05 15:09 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-31 17:21 Dave Jones
2017-06-03 6:33 ` [bisected] " Mike Galbraith
2017-06-04 8:32 ` Greg Kroah-Hartman
2017-06-04 9:02 ` Mike Galbraith
2017-06-04 10:00 ` Vegard Nossum
2017-06-04 11:34 ` Mike Galbraith
2017-06-05 15:09 ` Alan Cox [this message]
2017-06-05 15:41 ` Mike Galbraith
2017-06-05 4:52 ` [patch] tty: fix port buffer locking V2 Mike Galbraith
2017-06-05 6:48 ` Greg Kroah-Hartman
2017-06-05 7:16 ` Mike Galbraith
2017-06-07 2:07 ` [lkp-robot] [tty] 52b03e644f: calltrace:flush_to_ldisc kernel test robot
2017-06-07 2:25 ` Mike Galbraith
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170605160912.56c76d68@lxorguk.ukuu.org.uk \
--to=gnomes@lxorguk.ukuu.org.uk \
--cc=davej@codemonkey.org.uk \
--cc=efault@gmx.de \
--cc=gregkh@linuxfoundation.org \
--cc=jslaby@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=vegard.nossum@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®