linux-device-driver - 与 Linux 串行端口一起使用低延迟模式是否安全？

Question

Linux 串口使用 low_latency tty 模式安全吗？ tty_flip_buffer_push函数被记录为“如果设置了 port->low_latency，则不得从 IRQ 上下文调用它”。然而，无论标志是否设置，许多低级串行端口驱动程序都会从​​ ISR 调用它。例如，mpc52xx driver calls flip buffer每次从其 FIFO 读取后无条件地执行。

ISR 中的低延迟翻转缓冲区的结果是在 IRQ 上下文中输入线路规则驱动程序。我的目标是从高速 mpc52xx 串行端口读取一毫秒或更短的延迟。设置 low_latency 实现了延迟目标，但它也违反了 tty_flip_buffer_push 的记录先决条件。

Answer 1

这个问题是在 linux-serial on Fri, 19 Aug 2011 上提出的.

不，低延迟通常不安全。

但是，在 3.10.5 low_latency 的特殊情况下是安全的。

以上评论tty_flip_buffer_push读:

"This function must not be called from IRQ context if port->low_latency is set."

但是，代码(3.10.5，drivers/tty/tty_buffer.c)与此相矛盾:

void tty_flip_buffer_push(struct tty_port *port)
{
    struct tty_bufhead *buf = &port->buf;
    unsigned long flags;

    spin_lock_irqsave(&buf->lock, flags);
    if (buf->tail != NULL)
            buf->tail->commit = buf->tail->used;
    spin_unlock_irqrestore(&buf->lock, flags);

    if (port->low_latency)
            flush_to_ldisc(&buf->work);
    else
            schedule_work(&buf->work);
}
EXPORT_SYMBOL(tty_flip_buffer_push);

spin_lock_irqsave的使用/ spin_unlock_irqrestore使这段代码可以安全地从中断上下文调用。

有针对 low_latency 的测试如果设置了， flush_to_ldisc被直接调用。这会立即将翻转缓冲区刷新到线路规程，代价是使中断处理时间更长。 flush_to_ldisc例程也被编码为在中断上下文中使用是安全的。我猜早期版本是不安全的。

如 low_latency未设置，则 schedule_work叫做。调用 schedule_work是在中断上下文中从“上半部分”调用“下半部分”处理程序的经典方法。这会导致 flush_to_ldisc在下一个时钟滴答时从“下半部分”处理程序调用。

再深入一点，评论和测试似乎都在Alan Cox的原版 e0495736中 tty_buffer.c 的提交.这次提交是对早期代码的重写，因此似乎曾经没有测试。谁添加了测试并修复了 flush_to_ldisc中断安全没有费心修复评论。

所以，永远相信代码，而不是评论。

但是，在 3.12-rc* 中的相同代码(截至 2013 年 10 月 23 日)中，当删除 flush_to_ldisc 中的 spin_lock_irqsave 并添加 mutex_locks 时，问题似乎再次被打开。也就是说，在 serial_struct 标志中设置 UPF_LOW_LATENCY 并调用 TIOCSSERIAL ioctl 将再次导致“原子性调度”。

维护者的最新更新是:

On 10/19/2013 07:16 PM, Jonathan Ben Avraham wrote:
> Hi Peter,
> "tty_flip_buffer_push" is called from IRQ handlers in most drivers/tty/serial UART drivers.
> 
> "tty_flip_buffer_push" calls "flush_to_ldisc" if low_latency is set.
> "flush_to_ldisc" calls "mutex_lock" in 3.12-rc5, which cannot be used in interrupt context.
> 
> Does this mean that setting "low_latency" cannot be used safely in 3.12-rc5?

Yes, I broke low_latency.

Part of the problem is that the 3.11- use of low_latency was unsafe; too many shared
data areas were simply accessed without appropriate safeguards.

I'm working on fixing it but probably won't make it for 3.12 final.

Regards,
Peter Hurley

所以，看起来你不应该依赖 low_latency除非您确定永远不会从支持它的版本更改内核。

更新:2014 年 2 月 18 日，内核 3.13.2

斯坦尼斯拉夫·格鲁兹卡写道:

Hi,

setserial has low_latency option which should minimize receive latency
(scheduler delay). AFAICT it is used if someone talk to external device
via RS-485/RS-232 and need to have quick requests and responses . On
kernel this feature was implemented by direct tty processing from
interrupt context:

void tty_flip_buffer_push(struct tty_port *port)
{
    struct tty_bufhead *buf = &port->buf;

    buf->tail->commit = buf->tail->used;

    if (port->low_latency)
            flush_to_ldisc(&buf->work);
    else
            schedule_work(&buf->work);
} 

But after 3.12 tty locking changes, calling flush_to_ldisc() from
interrupt context is a bug (we got scheduling while atomic bug report
here: https://bugzilla.redhat.com/show_bug.cgi?id=1065087 )

I'm not sure how this should be solved. After Peter get rid all of those
race condition in tty layer, we probably don't want go back to use
spin_lock's there. Maybe we can create WQ_HIGHPRI workqueue and schedule
flush_to_ldisc() work there. Or perhaps users that need to low latency,
should switch to thread irq and prioritize serial irq to meat
retirements. Anyway setserial low_latency is now broken and all who use
this feature in the past can not do this any longer on 3.12+ kernels.

Thoughts ?

Stanislaw