All of lore.kernel.org
 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 10:59:25 +0100	[thread overview]
Message-ID: <YcBT/Vf41PWUYdxT@kroah.com> (raw)
In-Reply-To: <c35df81a176f418eb90e18563170de67@MAIL-MBX-cwP12.dji.com>

On Mon, Dec 20, 2021 at 09:44:04AM +0000, wigin zeng wrote:
> >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.

You did not answer my question about hardware type :(

And again, how is this happening?  If you use DMA, all data should be
coming through DMA and not the irq.  Otherwise crazy stuff like this
will happen in any type of driver, your hardware can not mix this type
of stuff up.

> >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

How can flow control handle this at all?  Flow control is at the serial
data stream level.  This is confusing the PCI data stream order.

thanks,

greg k-h

  reply	other threads:[~2021-12-20  9:59 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
2021-12-20  9:44               ` 答复: " wigin zeng
2021-12-20  9:59                 ` Greg KH [this message]
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=YcBT/Vf41PWUYdxT@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.