All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ardb@google.com>
To: linux-arm-kernel@lists.infradead.org
Cc: Ard Biesheuvel <ardb@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	 Will Deacon <will@kernel.org>, Marc Zyngier <maz@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	 Ryan Roberts <ryan.roberts@arm.com>,
	Anshuman Khandual <anshuman.khandual@arm.com>,
	 Kees Cook <keescook@chromium.org>
Subject: [PATCH v5 08/39] arm64: vmemmap: Avoid base2 order of struct page size to dimension region
Date: Fri, 24 Nov 2023 11:18:48 +0100	[thread overview]
Message-ID: <20231124101840.944737-49-ardb@google.com> (raw)
In-Reply-To: <20231124101840.944737-41-ardb@google.com>

From: Ard Biesheuvel <ardb@kernel.org>

The placement and size of the vmemmap region in the kernel virtual
address space is currently derived from the base2 order of the size of a
struct page. This makes for nicely aligned constants with lots of
leading 0xf and trailing 0x0 digits, but given that the actual struct
pages are indexed as an ordinary array, this resulting region is
severely overdimensioned when the size of a struct page is just over a
power of 2.

This doesn't matter today, but once we enable 52-bit virtual addressing
for 4k pages configurations, the vmemmap region may take up almost half
of the upper VA region with the current struct page upper bound at 64
bytes. And once we enable KMSAN or other features that push the size of
a struct page over 64 bytes, we will run out of VMALLOC space entirely.

So instead, let's derive the region size from the actual size of a
struct page, and place the entire region 1 GB from the top of the VA
space, where it still doesn't share any lower level translation table
entries with the fixmap.

Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
 arch/arm64/include/asm/memory.h | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index 2745bed8ae5b..b49575a92afc 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -30,8 +30,8 @@
  * keep a constant PAGE_OFFSET and "fallback" to using the higher end
  * of the VMEMMAP where 52-bit support is not available in hardware.
  */
-#define VMEMMAP_SHIFT	(PAGE_SHIFT - STRUCT_PAGE_MAX_SHIFT)
-#define VMEMMAP_SIZE	((_PAGE_END(VA_BITS_MIN) - PAGE_OFFSET) >> VMEMMAP_SHIFT)
+#define VMEMMAP_RANGE	(_PAGE_END(VA_BITS_MIN) - PAGE_OFFSET)
+#define VMEMMAP_SIZE	((VMEMMAP_RANGE >> PAGE_SHIFT) * sizeof(struct page))
 
 /*
  * PAGE_OFFSET - the virtual address of the start of the linear map, at the
@@ -47,8 +47,8 @@
 #define MODULES_END		(MODULES_VADDR + MODULES_VSIZE)
 #define MODULES_VADDR		(_PAGE_END(VA_BITS_MIN))
 #define MODULES_VSIZE		(SZ_2G)
-#define VMEMMAP_START		(-(UL(1) << (VA_BITS - VMEMMAP_SHIFT)))
-#define VMEMMAP_END		(VMEMMAP_START + VMEMMAP_SIZE)
+#define VMEMMAP_START		(VMEMMAP_END - VMEMMAP_SIZE)
+#define VMEMMAP_END		(-UL(SZ_1G))
 #define PCI_IO_START		(VMEMMAP_END + SZ_8M)
 #define PCI_IO_END		(PCI_IO_START + PCI_IO_SIZE)
 #define FIXADDR_TOP		(-UL(SZ_8M))
-- 
2.43.0.rc1.413.gea7ed67945-goog


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2023-11-24 10:21 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-24 10:18 [PATCH v5 00/39] arm64: Reorganize kernel VA space for LPA2 Ard Biesheuvel
2023-11-24 10:18 ` [PATCH v5 01/39] arm64: kernel: Disable latent_entropy GCC plugin in early C runtime Ard Biesheuvel
2023-11-24 10:18 ` [PATCH v5 02/39] arm64: mm: Take potential load offset into account when KASLR is off Ard Biesheuvel
2023-11-24 10:18 ` [PATCH v5 03/39] arm64: mm: get rid of kimage_vaddr global variable Ard Biesheuvel
2023-11-24 10:18 ` [PATCH v5 04/39] arm64: mm: Move PCI I/O emulation region above the vmemmap region Ard Biesheuvel
2023-11-24 10:18 ` [PATCH v5 05/39] arm64: mm: Move fixmap region above " Ard Biesheuvel
2023-11-24 10:18 ` [PATCH v5 06/39] arm64: ptdump: Allow all region boundaries to be defined at boot time Ard Biesheuvel
2023-11-24 10:18 ` [PATCH v5 07/39] arm64: ptdump: Discover start of vmemmap region at runtime Ard Biesheuvel
2023-11-24 10:18 ` Ard Biesheuvel [this message]
2023-11-24 10:18 ` [PATCH v5 09/39] arm64: mm: Reclaim unused vmemmap region for vmalloc use Ard Biesheuvel
2023-11-24 10:18 ` [PATCH v5 10/39] arm64: kaslr: Adjust randomization range dynamically Ard Biesheuvel
2023-11-24 10:18 ` [PATCH v5 11/39] arm64: kernel: Manage absolute relocations in code built under pi/ Ard Biesheuvel
2023-11-24 10:18 ` [PATCH v5 12/39] arm64: kernel: Don't rely on objcopy to make code under pi/ __init Ard Biesheuvel
2023-11-24 10:18 ` [PATCH v5 13/39] arm64: head: move relocation handling to C code Ard Biesheuvel
2023-11-24 10:18 ` [PATCH v5 14/39] arm64: idreg-override: Omit non-NULL checks for override pointer Ard Biesheuvel
2023-11-24 10:18 ` [PATCH v5 15/39] arm64: idreg-override: Prepare for place relative reloc patching Ard Biesheuvel
2023-11-27 12:53   ` Marc Zyngier
2023-11-27 12:58     ` Ard Biesheuvel
2023-11-24 10:18 ` [PATCH v5 16/39] arm64: idreg-override: Avoid parameq() and parameqn() Ard Biesheuvel
2023-11-24 10:18 ` [PATCH v5 17/39] arm64: idreg-override: avoid strlen() to check for empty strings Ard Biesheuvel
2023-11-24 10:18 ` [PATCH v5 18/39] arm64: idreg-override: Avoid sprintf() for simple string concatenation Ard Biesheuvel
2023-11-24 10:18 ` [PATCH v5 19/39] arm64: idreg-override: Avoid kstrtou64() to parse a single hex digit Ard Biesheuvel
2023-11-24 10:19 ` [PATCH v5 20/39] arm64: idreg-override: Move to early mini C runtime Ard Biesheuvel
2023-11-24 10:19 ` [PATCH v5 21/39] arm64: kernel: Remove early fdt remap code Ard Biesheuvel
2023-11-24 10:19 ` [PATCH v5 22/39] arm64: head: Clear BSS and the kernel page tables in one go Ard Biesheuvel
2023-11-24 10:19 ` [PATCH v5 23/39] arm64: Move feature overrides into the BSS section Ard Biesheuvel
2023-11-24 10:19 ` [PATCH v5 24/39] arm64: head: Run feature override detection before mapping the kernel Ard Biesheuvel
2023-11-24 10:19 ` [PATCH v5 25/39] arm64: head: move dynamic shadow call stack patching into early C runtime Ard Biesheuvel
2023-11-24 10:19 ` [PATCH v5 26/39] arm64: kaslr: Use feature override instead of parsing the cmdline again Ard Biesheuvel
2023-11-24 10:19 ` [PATCH v5 27/39] arm64/kernel: Move 'nokaslr' parsing out of early idreg code Ard Biesheuvel
2023-11-24 10:19 ` [PATCH v5 28/39] arm64: idreg-override: Create a pseudo feature for rodata=off Ard Biesheuvel
2023-11-24 10:19 ` [PATCH v5 29/39] arm64: Add helpers to probe local CPU for PAC and BTI support Ard Biesheuvel
2023-11-24 12:37   ` Marc Zyngier
2023-11-24 13:08     ` Ard Biesheuvel
2023-11-24 13:48       ` Marc Zyngier
2023-11-25  8:59         ` Ard Biesheuvel
2023-11-24 10:19 ` [PATCH v5 30/39] arm64: head: allocate more pages for the kernel mapping Ard Biesheuvel
2023-11-24 10:19 ` [PATCH v5 31/39] arm64: head: move memstart_offset_seed handling to C code Ard Biesheuvel
2023-11-24 10:19 ` [PATCH v5 32/39] arm64: mm: Make kaslr_requires_kpti() a static inline Ard Biesheuvel
2023-11-24 10:19 ` [PATCH v5 33/39] arm64: head: Move early kernel mapping routines into C code Ard Biesheuvel
2023-11-24 10:19 ` [PATCH v5 34/39] arm64: mm: Use 48-bit virtual addressing for the permanent ID map Ard Biesheuvel
2023-11-24 10:19 ` [PATCH v5 35/39] arm64: pgtable: Decouple PGDIR size macros from PGD/PUD/PMD levels Ard Biesheuvel
2023-11-24 10:19 ` [PATCH v5 36/39] arm64: kernel: Create initial ID map from C code Ard Biesheuvel
2023-11-24 10:19 ` [PATCH v5 37/39] arm64: mm: avoid fixmap for early swapper_pg_dir updates Ard Biesheuvel
2023-11-24 10:19 ` [PATCH v5 38/39] arm64: mm: omit redundant remap of kernel image Ard Biesheuvel
2023-11-24 10:19 ` [PATCH v5 39/39] arm64: Revert "mm: provide idmap pointer to cpu_replace_ttbr1()" Ard Biesheuvel
2023-11-24 16:22 ` [PATCH v5 00/39] arm64: Reorganize kernel VA space for LPA2 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=20231124101840.944737-49-ardb@google.com \
    --to=ardb@google.com \
    --cc=anshuman.khandual@arm.com \
    --cc=ardb@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=keescook@chromium.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --cc=ryan.roberts@arm.com \
    --cc=will@kernel.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.