mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Arnd Bergmann" <arnd@arndb.de>
To: "Jim Quinlan" <james.quinlan@broadcom.com>
Cc: "Linus Walleij" <linus.walleij@linaro.org>,
	"Christoph Hellwig" <hch@lst.de>,
	bcm-kernel-feedback-list@broadcom.com, jim2101024@gmail.com,
	"Russell King" <linux@armlinux.org.uk>,
	"Geert Uytterhoeven" <geert+renesas@glider.be>,
	"Russell King" <rmk+kernel@armlinux.org.uk>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Sebastian Reichel" <sebastian.reichel@collabora.com>,
	"Mike Rapoport" <rppt@kernel.org>,
	"Eric DeVolder" <eric.devolder@oracle.com>,
	"Nathan Chancellor" <nathan@kernel.org>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	"Christophe Leroy" <christophe.leroy@csgroup.eu>,
	"moderated list:ARM PORT" <linux-arm-kernel@lists.infradead.org>,
	"open list" <linux-kernel@vger.kernel.org>,
	"Claire Chang" <tientzu@chromium.org>,
	"Robin Murphy" <robin.murphy@arm.com>
Subject: Re: [PATCH v1 1/1] ARM: Select DMA_DIRECT_REMAP to fix restricted DMA
Date: Fri, 29 Sep 2023 15:52:17 -0400	[thread overview]
Message-ID: <edc3a774-adc0-4873-8ebe-a346b51cb9ca@app.fastmail.com> (raw)
In-Reply-To: <CA+-6iNwmkV0PagHehOhnYxOjwURhXZy-GnVzhkBL+9YaGMRmgQ@mail.gmail.com>

On Fri, Sep 29, 2023, at 15:24, Jim Quinlan wrote:
> On Thu, Sep 28, 2023 at 11:17 AM Arnd Bergmann <arnd@arndb.de> wrote:
>> On Thu, Sep 28, 2023, at 10:00, Jim Quinlan wrote:
>
> Our RC is definitely not coherent with the ARM/ARM64 caches.

Ok, thanks for the confirmation.

>> It's unlikely but not impossible, as the driver has some
>> unusual constructs, using a lot of coherent mappings that
>> might otherwise be streaming mappings, and relying on
>> dma_sync_single_for_device(..., DMA_BIDIRECTIONAL) for other
>> data, but without the corresponding dma_sync_single_for_cpu().
>> If all the testing happens on x86, this might easily lead
>> to a bug that only shows up on non-coherent systems but
>> is never seen during testing.
>>
>> If the problem is not the "dma-coherent" property, can you
>> double-check if using a different PCIe device works, or narrow
>> down which specific buffer you saw get corrupted?
>
> I've done some testing, below are the results.  The new two devices, a
> USB controller
> and an M2 NVMe stick, behave the same as iwlwifi.
>
> Note that I'm not advocating that "select DMA_DIRECT_REMAP" is the
> anser, I'm just showing that it fixes my examples.

Ok, so I think we can stop looking at the device drivers for
bugs then.

> VER      PCI-DEV                       <--------- RESTRICTED DMA --------->
>                       ARM64    ARM     ARM64    ARM    ARM+DMA_DIRECT_REMAP
> 5.15     iwlwifi        P       P        P       F             P
> 5.15     nvme           P       P        P       F             P
> 5.15     usb            P       P        P       F             P
>
> 6.1      iwlwifi        P       P        P       F             P
> 6.1      nvme           P       P        P       F             P
> 6.1      usb            P        P       P       F             P
>
> Upstrm   iwlwifi        P       P        F       F             F
> Upstrm   nvme           P       P        F       F             F
> Upstrm   usb            P       P        F       F             F
>                       ARM64    ARM     ARM64    ARM    ARM+DMA_DIRECT_REMAP
> VER      PCI-DEV                       <--------- RESTRICTED DMA --------->
>
> LEGEND:
>   P       := pass, driver probe and some functional test performed
>   F       := fail, usually when probe is called; impossible to do
> functional test
>   Upstrm  := 633b47cb009d "Merge tag 'scsi-fixes' of
> git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi"
>
>   iwlwifi := 7260 Wifi 8086:08b1
>   nvme    := 1e95:1007
>   usb     := Supahub, 1912:0014

Thanks for the thorough testing, that looks very useful, even though
I don't have an answer immediately. Maybe Robin can see something
here that I don't.

It's particularly interesting how arm64 only started failing
on fairly recent kernels, so if nothing else helps you could
always try bisecting the history between 6.1 and 633b47cb009d,
hoping that the commit that broke it points us to the arm32
problem.

The only change I see in that time frame that seems related
is 7bd6680b47fa ("Revert "Revert "arm64: dma: Drop cache
invalidation from arch_dma_prep_coherent()"""), so you could
start by reverting that. However, it's probably something
else since this is for the coherent mappings, not the
streaming ones.

       Arnd

  reply	other threads:[~2023-09-29 19:53 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-26 17:52 RFC: ARM && restricted DMA apparently not working Jim Quinlan
2023-09-26 17:52 ` [PATCH v1 1/1] ARM: Select DMA_DIRECT_REMAP to fix restricted DMA Jim Quinlan
2023-09-27  7:13   ` kernel test robot
2023-09-27 23:10   ` Linus Walleij
2023-09-28 12:07     ` Jim Quinlan
2023-09-28 13:09       ` Jim Quinlan
2023-09-28 13:32       ` Arnd Bergmann
2023-09-28 14:00         ` Jim Quinlan
2023-09-28 14:01           ` Jim Quinlan
2023-09-28 15:16           ` Arnd Bergmann
2023-09-28 15:33             ` Robin Murphy
2023-09-28 16:20               ` Arnd Bergmann
2023-09-29 19:24             ` Jim Quinlan
2023-09-29 19:52               ` Arnd Bergmann [this message]
2023-09-29 21:13                 ` Jim Quinlan
2023-10-01 12:48                 ` Jim Quinlan
2023-09-28 15:47       ` Robin Murphy
2023-10-02 12:33         ` Jim Quinlan
2023-10-02 15:08           ` Robin Murphy
2023-10-02  6:16     ` Christoph Hellwig
2023-10-05 17:53       ` Jim Quinlan
2023-10-06  7:40         ` Christoph Hellwig
     [not found]           ` <CGME20231020081648eucas1p17d2572cfca5762d2f5cbc560dd648564@eucas1p1.samsung.com>
2023-10-20  8:16             ` Marek Szyprowski
2023-10-23  6:16               ` Christoph Hellwig
2023-09-28 16:24   ` Christophe Leroy

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=edc3a774-adc0-4873-8ebe-a346b51cb9ca@app.fastmail.com \
    --to=arnd@arndb.de \
    --cc=akpm@linux-foundation.org \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=christophe.leroy@csgroup.eu \
    --cc=corbet@lwn.net \
    --cc=eric.devolder@oracle.com \
    --cc=geert+renesas@glider.be \
    --cc=hch@lst.de \
    --cc=james.quinlan@broadcom.com \
    --cc=jim2101024@gmail.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=nathan@kernel.org \
    --cc=rmk+kernel@armlinux.org.uk \
    --cc=robin.murphy@arm.com \
    --cc=rppt@kernel.org \
    --cc=sebastian.reichel@collabora.com \
    --cc=tglx@linutronix.de \
    --cc=tientzu@chromium.org \
    /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

all inboxes | Powered by JetHome®