Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 7 Jan 2016 15:02:00 +0100
From: Ard Biesheuvel <>
To: Mark Rutland <>
Cc: "" <>,, Will Deacon <>, 
	Catalin Marinas <>, Leif Lindholm <>, 
	Kees Cook <>, 
	"" <>, Stuart Yoder <>, 
	Sharma Bhupesh <>, Arnd Bergmann <>, 
	Marc Zyngier <>, Christoffer Dall <>
Subject: Re: [PATCH v2 03/13] arm64: use more granular reservations for static
 page table allocations

On 7 January 2016 at 14:55, Mark Rutland <> wrote:
> On Wed, Dec 30, 2015 at 04:26:02PM +0100, Ard Biesheuvel wrote:
>> Before introducing new statically allocated page tables and increasing
>> their alignment in subsequent patches, update the reservation logic
>> so that only pages that are in actual use end up as reserved with
>> memblock.
> Could you add something to the commit message about what this will gain
> us (i.e. which pages we don't have to reserve)? It's not immediately
> obvious why we'd have page tables we wouldn't want to reserve.

OK. In the original series, I also aligned the pgdir section to a log2
upper bound of its size, but that is not necessary anymore with your
changes. So the original goal was to avoid reserving the alignment
padding as well as the pgdirs that end up unused

> From the looks of the next patch we won't have redundant levels of
> fixmap table for a given configuration, so I guess we're catering for
> the case the fixmap shares a pgd/pud/pmd entry with the image mapping?
> Does that happen? If so that would invalidate the assumption I make when
> copying the fixmap over in [1] (see map_kernel).

It is a lot less likely to happen now that I moved the kernel to the
start of the vmalloc area rather than right below PAGE_OFFSET. But in
general, it seems sensible to only populate entries after confirming
that they are in fact vacant.

> To handle that either we need some special logic to copy over the
> relevant bits for the fixmap (as with kasan_copy_shadow), or we need to
> avoid sharing a pgd entry.
> Thoughts?

Yes, I have added that to my v3 version of the vmalloc base move patch here

but I think 16k/4 levels is the only config affected when the kernel
is always in the lower half of the vmalloc area. That also implies
that the fixmap pgd is either always shared, or never, depending on
the build time config, so I could probably simplify that part


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.