Message-ID: <c35df81a176f418eb90e18563170de67@MAIL-MBX-cwP12.dji.com>
Date:   Mon, 20 Dec 2021 09:44:04 +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

>That makes no sense, as what orders the data coming in?  The 2 bytes could be added to the tty buffer before the 512 bytes, or the other way around.

>What hardware are you using that is mixing dma and irq data like this?
>That feels very wrong.

It is not normal case, normally, the input size should smaller than DMA block size and DMA complete the whole copy.
However, there are some abnormal situations. The external input is unexpectedly larger than the data length of the DMA configuration. This situation in my example will appear, and it may cause the kernel to panic.

>If they are running on different cores, then you will have data corruption issues no matter if you have a lock or not, so this is not the correct solution for this hardware configuration problem.

The purpose of adding lock is to ensure that the kernel will not panic in this extreme case, If you want to ensure the integrity of the serial port data, you need to add more flow control logic

BRs
Weijun
-----邮件原件-----
发件人: Greg KH [mailto:gregkh@...uxfoundation.org] 
发送时间: 2021年12月20日 16:55
收件人: 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 Mon, Dec 20, 2021 at 05:27:24AM +0000, wigin zeng wrote:
> 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.

That makes no sense, as what orders the data coming in?  The 2 bytes could be added to the tty buffer before the 512 bytes, or the other way around.

What hardware are you using that is mixing dma and irq data like this?
That feels very wrong.

> >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 they are running on different cores, then you will have data corruption issues no matter if you have a lock or not, so this is not the correct solution for this hardware configuration problem.

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.

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

Powered by blists - more mailing lists