Message-ID: <62dd5f2fedbb4332a4d04dea4970a347@MAIL-MBX-cwP12.dji.com>
Date:   Mon, 20 Dec 2021 05:27:24 +0000
From:   wigin zeng <wigin.zeng@....com>
To:     Greg KH <gregkh@...uxfoundation.org>
CC:     "jirislaby@...nel.org" <jirislaby@...nel.org>,
        "linux-serial@...r.kernel.org" <linux-serial@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        First Light <xiaoguang.chen@....com>
Subject: 答复: 答复: 答复: [PATCH] serial: 8250: add lock for dma rx

Sorry for late response.

> >> What issue exactly?
> The interval of UART input packages is very small(1ms~ 10ms), and some package size larger than configured DMA transfer size.
>What do you mean exactly by "package size"?  Isn't it up to the DMA transfer to do the whole copy?
 
The attachment is an example for the race condition issue. E.g: 514bytes input stream from UART, 512bytes should be copied by DMA(block size set as 512), left 2bytes should be copied by serial interrupt handler.

>Again, what changed recently to cause this to start happening?  Why is this only showing up now?  What is unique about your system that causes this and prevents it from happening on any other system?
I think it is a corner case and exist in previous kernel version, we just reproduced it in pressure test.
Our system running multi cores and enabled RT feature, DMA interrupt thread and serial interrupt thread are running on different cores in parallel.
If there is no sync lock, will easy to reproduce.

BRs
Weijun
-----邮件原件-----
发件人: Greg KH [mailto:gregkh@...uxfoundation.org] 
发送时间: 2021年12月9日 18:07
收件人: wigin zeng <wigin.zeng@....com>
抄送: jirislaby@...nel.org; linux-serial@...r.kernel.org; linux-kernel@...r.kernel.org; First Light <xiaoguang.chen@....com>
主题: Re: 答复: 答复: [PATCH] serial: 8250: add lock for dma rx

【EXTERNAL EMAIL】 DO NOT CLICK any links or attachments unless you can make sure both the sender and the content are trustworthy.


【外部邮件提醒】以下邮件来源于公司外部，请勿点击链接或附件，除非您确认邮件发件人和内容可信。



On Thu, Dec 09, 2021 at 09:08:51AM +0000, wigin zeng wrote:
> > What issue exactly?
> The interval of UART input packages is very small(1ms~ 10ms), and some package size larger than configured DMA transfer size.

What do you mean exactly by "package size"?  Isn't it up to the DMA transfer to do the whole copy?

> > But what data is being accessed at the same time to cause a crash?
> > How is data being added into the buffer at the same time in two different places into the same queue?  What userspace programs are causing this?
> Both places will modify tty_port *port->buf.tail (kmalloc operation 
> and write the data/flag into this address)

What is the "second" place here?  Data should only be coming in from the DMA transfer copy, right?

> >So all tty buffer accesses need to be protected by your new lock?
> New lock only protected the tty_buffer alloc and write operation in serial-tty case.

You need to document that really well as it does not seem that all accesses are now protected by this lock.  Only one odd access is, and I still do not understand how this is happening at the same time now.

Again, what changed recently to cause this to start happening?  Why is this only showing up now?  What is unique about your system that causes this and prevents it from happening on any other system?

thanks,

greg k-h
This email and any attachments thereto may contain private, confidential, and privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.

此电子邮件及附件所包含内容具有机密性，且仅限于接收人使用。未经允许，禁止第三人阅读、复制或传播该电子邮件中的任何信息。如果您不属于以上电子邮件的目标接收者，请您立即通知发送人并删除原电子邮件及其相关的附件。

Download attachment "serial_dma_race_condition.jpg" of type "image/jpeg" (44410 bytes)

Powered by blists - more mailing lists