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: <52ED0E0F.5050300@hurleysoftware.com>
Date:	Sat, 01 Feb 2014 10:09:03 -0500
From:	Peter Hurley <peter@...leysoftware.com>
To:	Pavel Roskin <proski@....org>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
CC:	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 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

Although it used to mean 'process the input immediately even in
interrupt context', it has become 'the device doesn't receive data
in interrupt context so process the data now'.

> But how should a real low_latency device work?

A low_latency device does not receive data in interrupt context;
ie., tty_flip_buffers() cannot be called from an irq handler
or with interrupts disabled.

> Are they supported by 8250_core?

yes

> Do they have hard IRQs?

possibly but not for rx

> Are those IRQs handled by serial8250_handle_irq()?

possibly, but again not for rx

> If DMA is not used, then serial8250_rx_chars() is the only way to receive data.
> But serial8250_rx_chars() calls tty_flip_buffer_push() unconditionally,
> and the later should not be called from the IRQ context for low_latency devices,
> if the comment about it is to be trusted.

Exactly.

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

Regards,
Peter Hurley


--
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/