On Tue, Oct 08, 2024 at 07:50:24PM -0700, John Hubbard wrote: > For clarity. It's increasingly hard to reason about the code, when KASLR > is moving around the boundaries. In this case where KASLR is randomizing > the location of the kernel image within physical memory, the maximum > number of address bits for physical memory has not changed. > > What has changed is the ending address of memory that is allowed to be > directly mapped by the kernel. > > Let's name the variable, and the associated macro accordingly. > > Also, enhance the comment above the direct_map_physmem_end definition, > to further clarify how this all works. > > Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx> > Cc: Alistair Popple <apopple@xxxxxxxxxx> > Cc: Jordan Niethe <jniethe@xxxxxxxxxx> > Cc: David Hildenbrand <david@xxxxxxxxxx> > Signed-off-by: John Hubbard <jhubbard@xxxxxxxxxx> > --- > > David Hildenbrand, I recall you had an unanswered question in this > vicinity [1] when tglx's recent kaslr fix was being reviewed. Maybe this > will help with that. > > > [1] https://lore.kernel.org/linux-mm/ee205448-5fdd-495e-9d7c-c8a2b59f9c9e@xxxxxxxxxxxx/T/#mdf442f077c9023590e144dbed2b04a109793484d > > thanks, > John Hubbard > > > arch/arm64/include/asm/memory.h | 2 +- > arch/x86/include/asm/page_64.h | 2 +- > arch/x86/include/asm/pgtable_64_types.h | 2 +- > arch/x86/mm/init_64.c | 2 +- > arch/x86/mm/kaslr.c | 14 +++++++++----- > include/linux/mm.h | 6 +++--- > kernel/resource.c | 4 ++-- > mm/memory_hotplug.c | 2 +- > mm/sparse.c | 2 +- > 9 files changed, 20 insertions(+), 16 deletions(-) For arm64: Acked-by: Will Deacon <will@xxxxxxxxxx> Will
