linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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

  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 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).