From: Catalin Marinas <catalin.marinas@arm.com>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Will Deacon <will@kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
kernel-hardening@lists.openwall.com,
Mark Rutland <mark.rutland@arm.com>
Subject: Re: [RFC PATCH] arm64: remove CONFIG_DEBUG_ALIGN_RODATA feature
Date: Thu, 2 Apr 2020 12:30:33 +0100 [thread overview]
Message-ID: <20200402113033.GD21087@mbp> (raw)
In-Reply-To: <CAMj1kXFcvHcU2kzP=N4bHgSkw_eE7wvbPJ=7w1pNeCWHbcPvTQ@mail.gmail.com>
On Mon, Mar 30, 2020 at 04:32:31PM +0200, Ard Biesheuvel wrote:
> On Mon, 30 Mar 2020 at 16:28, Will Deacon <will@kernel.org> wrote:
> > > On Mon, 30 Mar 2020 at 16:04, Will Deacon <will@kernel.org> wrote:
> > > > On Mon, Mar 30, 2020 at 03:53:04PM +0200, Ard Biesheuvel wrote:
> > > > > On Mon, 30 Mar 2020 at 15:51, Will Deacon <will@kernel.org> wrote:
> > > > > > But I would really like to go a step further and rip out the block mapping
> > > > > > support altogether so that we can fix non-coherent DMA aliases:
> > > > > >
> > > > > > https://lore.kernel.org/lkml/20200224194446.690816-1-hch@lst.de
> > > > >
> > > > > I'm not sure I follow - is this about mapping parts of the static
> > > > > kernel Image for non-coherent DMA?
> > > >
> > > > Sorry, it's not directly related to your patch, just that if we're removing
> > > > options relating to kernel mappings then I'd be quite keen on effectively
> > > > forcing page-granularity on the linear map, as is currently done by default
> > > > thanks to RODATA_FULL_DEFAULT_ENABLED, so that we can nobble cacheable
> > > > aliases for non-coherent streaming DMA mappings by hooking into Christoph's
> > > > series above.
Have we ever hit this issue in practice? At least from the CPU
perspective, we've assumed that a non-cacheable access would not hit in
the cache. Reading the ARM ARM rules, it doesn't seem to state this
explicitly but we can ask for clarification (I dug out an email from
2015, left unanswered).
Assuming that the CPU is behaving as we'd expect, are there other issues
with peripherals/SMMU?
> > Fair enough, but I'd still like to see some numbers. If they're compelling,
> > then we could explore something like CONFIG_OF_DMA_DEFAULT_COHERENT, but
> > that doesn't really help the kconfig maze :(
I'd prefer not to have a config option, we could easily break single
Image at some point.
> Could we make this a runtime thing? E.g., remap the entire linear
> region down to pages under stop_machine() the first time we probe a
> device that uses non-coherent DMA?
That could be pretty expensive at run-time. With the ARMv8.4-TTRem
feature, I wonder whether we could do this lazily when allocating
non-coherent DMA buffers.
(I still hope there isn't a problem at all with this mismatch ;)).
--
Catalin
next prev parent reply other threads:[~2020-04-02 12:48 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-29 14:12 [RFC PATCH] arm64: remove CONFIG_DEBUG_ALIGN_RODATA feature Ard Biesheuvel
2020-03-30 11:29 ` Mark Rutland
2020-03-30 12:36 ` Ard Biesheuvel
2020-03-30 13:51 ` Will Deacon
2020-03-30 13:53 ` Ard Biesheuvel
2020-03-30 13:59 ` Robin Murphy
2020-03-30 14:04 ` Will Deacon
2020-03-30 14:22 ` Ard Biesheuvel
2020-03-30 14:28 ` Will Deacon
2020-03-30 14:32 ` Ard Biesheuvel
2020-04-02 11:30 ` Catalin Marinas [this message]
2020-04-02 12:17 ` Mark Rutland
2020-04-03 7:07 ` Will Deacon
2020-04-03 8:58 ` Ard Biesheuvel
2020-05-05 10:44 ` Will Deacon
2020-05-07 13:43 ` Catalin Marinas
2020-03-30 13:57 ` Laura Abbott
2020-04-02 11:15 ` Catalin Marinas
2020-04-02 11:24 ` Ard Biesheuvel
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=20200402113033.GD21087@mbp \
--to=catalin.marinas@arm.com \
--cc=ardb@kernel.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=mark.rutland@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).