From: Catalin Marinas <catalin.marinas@arm.com>
To: Will Deacon <will@kernel.org>
Cc: Robin Murphy <robin.murphy@arm.com>,
Christoph Hellwig <hch@lst.de>,
linux-arm-kernel@lists.infradead.org,
Mark Rutland <mark.rutland@arm.com>,
Ard Biesheuvel <ardb@kernel.org>
Subject: Re: [PATCH] arm64: dma: Drop cache invalidation from arch_dma_prep_coherent()
Date: Thu, 8 Sep 2022 16:49:03 +0100 [thread overview]
Message-ID: <YxoO7xmB24/bpycc@arm.com> (raw)
In-Reply-To: <YxnEr8k5Sq1dZFnu@arm.com>
On Thu, Sep 08, 2022 at 11:32:15AM +0100, Catalin Marinas wrote:
> On Wed, Sep 07, 2022 at 05:25:43PM +0100, Will Deacon wrote:
> > On Wed, Sep 07, 2022 at 10:27:45AM +0100, Robin Murphy wrote:
> > > It seems like we don't stand to gain much by removing the invalidation -
> > > since the overhead will still be in the clean - other than the potential for
> > > a slightly increased chance of rare and hard-to-debug memory corruption :/
> >
> > I just find it odd that we rely on the CPU not hitting the cacheable alias
> > in other places, yet we're using an invalidation for this path. It's
> > inconsistent and difficult to explain to people. As I said, I'm happy to
> > add a comment to the existing code instead of the change here, but I don't
> > know what to say other than something like:
> >
> > /*
> > * The architecture says we only need a clean here, but invalidate as
> > * well just in case.
> > */
[...]
> So yeah, I think a clean is needed here or clean+invalidate but not
> invalidate only due to the addition of MTE.
OK, I think invalidate works as well. The ARM ARM has a note on the DC
IVAC instruction:
When FEAT_MTE is implemented, this instruction might invalidate
Allocation Tags from caches. When it invalidates Allocation Tags from
caches, it also cleans them.
(hopefully it cleans them first before invalidating)
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-09-08 15:52 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-23 12:21 [PATCH] arm64: dma: Drop cache invalidation from arch_dma_prep_coherent() Will Deacon
2022-08-24 9:58 ` Ard Biesheuvel
2022-08-24 11:23 ` Will Deacon
2022-08-24 11:49 ` Ard Biesheuvel
2022-08-24 22:00 ` Catalin Marinas
2022-09-07 9:04 ` Christoph Hellwig
2022-09-07 14:10 ` Russell King (Oracle)
2022-09-07 14:14 ` Christoph Hellwig
2022-09-07 14:15 ` Russell King (Oracle)
2022-09-07 9:03 ` Christoph Hellwig
2022-09-07 9:27 ` Robin Murphy
2022-09-07 16:25 ` Will Deacon
2022-09-07 17:50 ` Robin Murphy
2022-09-08 10:32 ` Catalin Marinas
2022-09-08 11:32 ` Robin Murphy
2022-09-08 13:02 ` Catalin Marinas
2022-09-08 13:27 ` Catalin Marinas
2022-09-08 13:32 ` Will Deacon
2022-09-08 15:49 ` Catalin Marinas [this message]
2022-09-07 16:28 ` Will Deacon
2022-09-22 20:02 ` Catalin Marinas
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=YxoO7xmB24/bpycc@arm.com \
--to=catalin.marinas@arm.com \
--cc=ardb@kernel.org \
--cc=hch@lst.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=robin.murphy@arm.com \
--cc=will@kernel.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 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.