Linux Serial subsystem development
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: wigin zeng <wigin.zeng@dji.com>
Cc: "jirislaby@kernel.org" <jirislaby@kernel.org>,
	"linux-serial@vger.kernel.org" <linux-serial@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	First Light <xiaoguang.chen@dji.com>
Subject: Re: 答复: 答复: 答复: [PATCH] serial: 8250: add lock for dma rx
Date: Mon, 20 Dec 2021 09:54:35 +0100	[thread overview]
Message-ID: <YcBEy9zi2G7UYErE@kroah.com> (raw)
In-Reply-To: <62dd5f2fedbb4332a4d04dea4970a347@MAIL-MBX-cwP12.dji.com>

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

  reply	other threads:[~2021-12-20  8:54 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20211209073339.21694-1-wigin.zeng@dji.com>
2021-12-09  7:38 ` [PATCH] serial: 8250: add lock for dma rx Greg KH
2021-12-09  8:15   ` 答复: " wigin zeng
2021-12-09  8:42     ` Greg KH
2021-12-09  9:08       ` 答复: " wigin zeng
2021-12-09 10:07         ` Greg KH
2021-12-20  5:27           ` 答复: " wigin zeng
2021-12-20  8:54             ` Greg KH [this message]
2021-12-20  9:44               ` 答复: " wigin zeng
2021-12-20  9:59                 ` Greg KH
2021-12-20 10:25                   ` 答复: " wigin zeng
2021-12-20 10:40                     ` Greg KH
2021-12-30  4:41                       ` 答复: " wigin zeng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YcBEy9zi2G7UYErE@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=jirislaby@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=wigin.zeng@dji.com \
    --cc=xiaoguang.chen@dji.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox