From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 1/6] arm64: vmemmap: use virtual projection of linear region
Date: Fri, 26 Feb 2016 16:24:15 +0000 [thread overview]
Message-ID: <20160226162415.GG29125@arm.com> (raw)
In-Reply-To: <CAKv+Gu9Os3ZOepFDYTCQxfkWkhQUMbWyc_N=c5DNFgzmkAx0ZQ@mail.gmail.com>
On Fri, Feb 26, 2016 at 04:39:55PM +0100, Ard Biesheuvel wrote:
> On 26 February 2016 at 16:15, Will Deacon <will.deacon@arm.com> wrote:
> > On Thu, Feb 25, 2016 at 08:02:00AM +0100, Ard Biesheuvel wrote:
> >> On 24 February 2016 at 17:21, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> >> > diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> >> > index a440f5a85d08..8e6baea0ff61 100644
> >> > --- a/arch/arm64/include/asm/pgtable.h
> >> > +++ b/arch/arm64/include/asm/pgtable.h
> >> > @@ -34,18 +34,19 @@
> >> > /*
> >> > * VMALLOC and SPARSEMEM_VMEMMAP ranges.
> >> > *
> >> > - * VMEMAP_SIZE: allows the whole VA space to be covered by a struct page array
> >> > + * VMEMAP_SIZE: allows the whole linear region to be covered by a struct page array
> >> > * (rounded up to PUD_SIZE).
> >> > * VMALLOC_START: beginning of the kernel vmalloc space
> >> > * VMALLOC_END: extends to the available space below vmmemmap, PCI I/O space,
> >> > * fixed mappings and modules
> >> > */
> >> > -#define VMEMMAP_SIZE ALIGN((1UL << (VA_BITS - PAGE_SHIFT)) * sizeof(struct page), PUD_SIZE)
> >> > +#define VMEMMAP_SIZE ALIGN((1UL << (VA_BITS - PAGE_SHIFT - 1)) * sizeof(struct page), PUD_SIZE)
> >> >
> >> > #define VMALLOC_START (MODULES_END)
> >> > #define VMALLOC_END (PAGE_OFFSET - PUD_SIZE - VMEMMAP_SIZE - SZ_64K)
> >> >
> >> > -#define vmemmap ((struct page *)(VMALLOC_END + SZ_64K))
> >> > +#define VMEMMAP_START (VMALLOC_END + SZ_64K)
> >> > +#define vmemmap ((struct page *)(VMEMMAP_START - memstart_addr / sizeof(struct page)))
> >> >
> >>
> >> Note that with the linear region randomization which is now in -next,
> >> this division needs to be signed (since memstart_addr can wrap).
> >>
> >> So I should either update the definition of memstart_addr to s64 in
> >> this patch, or cast to (s64) in the expression above
> >
> > Can you avoid the division altogether by doing something like:
> >
> > (struct page *)(VMEMMAP_START - (PHYS_PFN(memstart_addr) * sizeof(struct page)))
> >
> > or have I misunderstood how this works?
> >
>
> It needs to be a signed shift, since the RHS of the subtraction must
> remain negative if memstart_addr is 'negative'
>
> This works as well:
> (struct page *)VMEMMAP_START - ((s64)memstart_addr >> PAGE_SHIFT)
Ah yeah, even better.
> It may be appropriate to change the definition of memstart_addr to
> s64, to reflect that, under randomization of the linear region, the
> start of physical memory may be 'below zero' so that the actual
> populated RAM region is high up in the linear region.
> That way, we can lose the case here.
That sounds like a good idea.
Will
next prev parent reply other threads:[~2016-02-26 16:24 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-24 16:21 [RFC PATCH 0/6] restrict virt_to_page to linear region (instead of __pa) Ard Biesheuvel
2016-02-24 16:21 ` [RFC PATCH 1/6] arm64: vmemmap: use virtual projection of linear region Ard Biesheuvel
2016-02-25 7:02 ` Ard Biesheuvel
2016-02-26 15:15 ` Will Deacon
2016-02-26 15:39 ` Ard Biesheuvel
2016-02-26 16:24 ` Will Deacon [this message]
2016-02-26 16:26 ` Ard Biesheuvel
2016-02-24 16:21 ` [RFC PATCH 2/6] arm64: vdso: avoid virt_to_page() translations on kernel symbols Ard Biesheuvel
2016-02-24 16:21 ` [RFC PATCH 3/6] arm64: mm: free __init memory via the linear mapping Ard Biesheuvel
2016-02-24 16:21 ` [RFC PATCH 4/6] arm64: mm: avoid virt_to_page() translation for the zero page Ard Biesheuvel
2016-02-24 16:21 ` [RFC PATCH 5/6] kernel: insn: avoid virt_to_page() translations on core kernel symbols Ard Biesheuvel
2016-02-24 16:21 ` [RFC PATCH 6/6] arm64: mm: disregard PHYS_OFFSET in virt_to_page() 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=20160226162415.GG29125@arm.com \
--to=will.deacon@arm.com \
--cc=linux-arm-kernel@lists.infradead.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.