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

[Peter Hurley <peter@hurleysoftware.com>]

On 01/14/2014 11:24 AM, Pavel Roskin wrote:
> Hi Alan,
>
> Quoting One Thousand Gnomes <gnomes@lxorguk.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