From: will.deacon@arm•com (Will Deacon)
To: linux-arm-kernel@lists•infradead.org
Subject: [RFC PATCH 10/10] arm64: mm: restrict __pa() translations to linear virtual addresses
Date: Tue, 23 Feb 2016 12:31:51 +0000 [thread overview]
Message-ID: <20160223123151.GK3966@arm.com> (raw)
In-Reply-To: <CAKv+Gu_zdt-sk_moCeF8u95DCZgcT26CDH1gL87Q4qXKA_hKrg@mail.gmail.com>
On Tue, Feb 23, 2016 at 01:29:21PM +0100, Ard Biesheuvel wrote:
> On 23 February 2016 at 13:26, Will Deacon <will.deacon@arm•com> wrote:
> > On Mon, Feb 22, 2016 at 09:54:32PM +0100, Ard Biesheuvel wrote:
> >> Now that we have replaced all occurrences of __pa() translations
> >> involving virtual addresses that are covered by the kernel text,
> >> we can redefine __virt_to_phys and __pa() etc to only take virtual
> >> address that are covered by the linear mapping. This means we can
> >> remove the comparison with PAGE_OFFSET in the definition of
> >> __virt_to_phys().
> >>
> >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro•org>
> >> ---
> >> arch/arm64/include/asm/memory.h | 12 +++++++-----
> >> 1 file changed, 7 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> >> index 56d6739430f3..3b5dc5b243ac 100644
> >> --- a/arch/arm64/include/asm/memory.h
> >> +++ b/arch/arm64/include/asm/memory.h
> >> @@ -86,11 +86,14 @@
> >> * private definitions which should NOT be used outside memory.h
> >> * files. Use virt_to_phys/phys_to_virt/__pa/__va instead.
> >> */
> >> -#define __virt_to_phys(x) ({ \
> >> +#ifndef CONFIG_DEBUG_VM
> >> +#define __virt_to_phys(x) (((phys_addr_t)(x) & ~PAGE_OFFSET) + PHYS_OFFSET)
> >> +#else
> >> +#define __virt_to_phys(x) ({ \
> >> phys_addr_t __x = (phys_addr_t)(x); \
> >> - __x & BIT(VA_BITS - 1) ? (__x & ~PAGE_OFFSET) + PHYS_OFFSET : \
> >> - (__x - kimage_voffset); })
> >> -
> >> + BUG_ON(__x < PAGE_OFFSET); \
> >> + (((phys_addr_t)__x & ~PAGE_OFFSET) + PHYS_OFFSET); })
> >
> > What's the #include-hell like if you try to use VM_BUG_ON instead?
> >
>
> The #include hell would not change I think, since
>
> include/linux/mmdebug.h:18:#define VM_BUG_ON(cond) BUG_ON(cond)
>
> but it would certainly make this code look a lot cleaner.
Yup, and likewise for PHYS_OFFSET.
Will
next prev parent reply other threads:[~2016-02-23 12:31 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-22 20:54 [RFC PATCH 00/10] arm64: restrict __pa translation to linear virtual addresses Ard Biesheuvel
2016-02-22 20:54 ` [RFC PATCH 01/10] arm64: mm: move assignment of 'high_memory' before its first use Ard Biesheuvel
2016-02-23 12:14 ` Catalin Marinas
2016-02-23 12:18 ` Ard Biesheuvel
2016-02-22 20:54 ` [RFC PATCH 02/10] arm64: introduce __kimg_to_phys() and __pa_symbol() Ard Biesheuvel
2016-02-22 20:54 ` [RFC PATCH 03/10] arm64: mm: avoid __pa translations in cpu_replace_ttbr1 Ard Biesheuvel
2016-02-22 20:54 ` [RFC PATCH 04/10] arm64: mm: avoid __pa translations on empty_zero_page Ard Biesheuvel
2016-02-22 20:54 ` [RFC PATCH 05/10] arm64: mm: avoid __pa translations in early_fixmap_init Ard Biesheuvel
2016-02-23 17:12 ` Catalin Marinas
2016-02-23 17:16 ` Ard Biesheuvel
2016-02-23 17:26 ` Catalin Marinas
2016-02-23 17:27 ` Ard Biesheuvel
2016-02-23 17:32 ` Catalin Marinas
2016-02-23 17:43 ` Ard Biesheuvel
2016-02-23 18:10 ` Catalin Marinas
2016-02-22 20:54 ` [RFC PATCH 06/10] arm64: mm: use __pa_symbol() not __pa() for section boundary symbols Ard Biesheuvel
2016-02-22 20:54 ` [RFC PATCH 07/10] arm64: mm: avoid __pa translations for idmap_pg_dir and swapper_pg_dir Ard Biesheuvel
2016-02-22 20:54 ` [RFC PATCH 08/10] arm64: vdso: avoid __pa translations Ard Biesheuvel
2016-02-22 20:54 ` [RFC PATCH 09/10] arm64: insn: " Ard Biesheuvel
2016-02-22 20:54 ` [RFC PATCH 10/10] arm64: mm: restrict __pa() translations to linear virtual addresses Ard Biesheuvel
2016-02-23 12:26 ` Will Deacon
2016-02-23 12:29 ` Ard Biesheuvel
2016-02-23 12:31 ` Will Deacon [this message]
2016-02-23 17:22 ` Catalin Marinas
2016-02-23 10:03 ` [RFC PATCH 00/10] arm64: restrict __pa translation " 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=20160223123151.GK3966@arm.com \
--to=will.deacon@arm$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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