linux-device-driver – 低延迟模式是否可以安全地与Linux串行端

不,低延迟通常不安全.

但是,在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的tty_buffer.c的原始e0495736提交中.这个提交是对早期代码的重写,所以似乎有一次没有测试.无论谁添加测试并修复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

Stanislaw Gruszka写道：

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