linux-kernel - Re: serial8250: bogus low_latency destabilizes kernel, need sanity check

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140203111040.4cafe560@alan.etchedpixels.co.uk>
Date:	Mon, 3 Feb 2014 11:10:40 +0000
From:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To:	Peter Hurley <peter@...leysoftware.com>
Cc:	Pavel Roskin <proski@....org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Jiri Slaby <jslaby@...e.cz>, linux-kernel@...r.kernel.org
Subject: Re: serial8250: bogus low_latency destabilizes kernel, need sanity
 check

On Sat, 01 Feb 2014 10:09:03 -0500
Peter Hurley <peter@...leysoftware.com> wrote:

> On 01/14/2014 11:24 AM, Pavel Roskin wrote:
> > Hi Alan,
> >
> > Quoting One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>:
> >
> >>> Maybe we should unset the low_latency flag as soon as DMA fails?  There
> >>> are two flags, one is state->uart_port->flags and the other is
> >>> port->low_latency.  I guess we need to unset both.
> >>
> >> Well low latency and DMA are pretty much exclusive in the real world so
> >> probably DMA ports shouldn't allow low_latency to be set at all in DMA
> >> mode.
> >
> > That's a useful insight.  I assumed exactly the opposite.
> 
> The meaning of low_latency has migrated since 2.6.28

Not really. The meaning of low latency was always "get the turn around
time for command/response protocols down as low as possible". DMA driven
serial usually reports a transfer completion on a watermark or a timeout,
so tends to work very badly within the Linux definition of 'low latency'
for tty.

What it does has certainly changed but thats implementation detail.

> Perhaps we should unconditionally unset low_latency (or remove it entirely).
> Real low latency can be addressed by using the -RT kernel.

Just saying "use -RT" would be a regression and actually hurt quite a few
annoying "simple protocol" using tools for all sorts of control systems.
We are talking about milliseconds not microseconds here.

The expected behaviour in low_latency is probably best described as

data arrives
processed
wakeup

and to avoid the case of

data arrives
queued for back end
[up to 10mS delay, but typically 1-2mS]
processed
wakeup

which multipled over a 50,000 S record download is a lot of time

Everything else is not user visible so can be changed freely to get that
assumption to work (including ending up not needing it in the first
place).

Getting tty to the point everything but N_TTY canonical mode is a fast
path would probably eliminate the need nicely - I don't know of any use
cases that expect ICANON, ECHO or I*/O* processing for low latency.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/