public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ardb+git@google.com>
To: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org, will@kernel.org,
	 catalin.marinas@arm.com, mark.rutland@arm.com,
	 Ard Biesheuvel <ardb@kernel.org>,
	Ryan Roberts <ryan.roberts@arm.com>,
	 Anshuman Khandual <anshuman.khandual@arm.com>,
	Liz Prucka <lizprucka@google.com>,
	 Seth Jenkins <sethjenkins@google.com>,
	Kees Cook <kees@kernel.org>,
	 linux-hardening@vger.kernel.org
Subject: [PATCH v3 03/13] arm64: mm: Preserve non-contiguous descriptors when mapping DRAM
Date: Fri, 20 Mar 2026 15:59:38 +0100	[thread overview]
Message-ID: <20260320145934.2349881-18-ardb+git@google.com> (raw)
In-Reply-To: <20260320145934.2349881-15-ardb+git@google.com>

From: Ard Biesheuvel <ardb@kernel.org>

Instead of blindly overwriting existing live entries with the contiguous
bit cleared when mapping DRAM regions, check whether the contiguous
region in question starts with a descriptor that has the valid bit set
and the contiguous bit cleared, and in that case, leave the contiguous
bit unset on the entire region. This permits the logic of mapping the
kernel's linear alias to be simplified in a subsequent patch.

Note that not setting the contiguous bit on any of the descriptors in
the contiguous region can only result in an invalid configuration if it
was already invalid to begin with.

Reviewed-by: Ryan Roberts <ryan.roberts@arm.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
 arch/arm64/include/asm/pgtable.h | 4 ++++
 arch/arm64/mm/mmu.c              | 6 ++++--
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index b3e58735c49b..dc007043d86b 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -187,6 +187,10 @@ static inline pteval_t __phys_to_pte_val(phys_addr_t phys)
  * Returns true if the pte is valid and has the contiguous bit set.
  */
 #define pte_valid_cont(pte)	(pte_valid(pte) && pte_cont(pte))
+/*
+ * Returns true if the pte is valid and has the contiguous bit cleared.
+ */
+#define pte_valid_noncont(pte)	(pte_valid(pte) && !pte_cont(pte))
 /*
  * Could the pte be present in the TLB? We must check mm_tlb_flush_pending
  * so that we don't erroneously return false for pages that have been
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 9927b55022d8..7f7d63009440 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -230,7 +230,8 @@ static int alloc_init_cont_pte(pmd_t *pmdp, unsigned long addr,
 
 		/* use a contiguous mapping if the range is suitably aligned */
 		if ((((addr | next | phys) & ~CONT_PTE_MASK) == 0) &&
-		    (flags & NO_CONT_MAPPINGS) == 0)
+		    (flags & NO_CONT_MAPPINGS) == 0 &&
+		    !pte_valid_noncont(__ptep_get(ptep)))
 			__prot = __pgprot(pgprot_val(prot) | PTE_CONT);
 
 		init_pte(ptep, addr, next, phys, __prot);
@@ -330,7 +331,8 @@ static int alloc_init_cont_pmd(pud_t *pudp, unsigned long addr,
 
 		/* use a contiguous mapping if the range is suitably aligned */
 		if ((((addr | next | phys) & ~CONT_PMD_MASK) == 0) &&
-		    (flags & NO_CONT_MAPPINGS) == 0)
+		    (flags & NO_CONT_MAPPINGS) == 0 &&
+		    !pte_valid_noncont(pmd_pte(READ_ONCE(*pmdp))))
 			__prot = __pgprot(pgprot_val(prot) | PTE_CONT);
 
 		ret = init_pmd(pmdp, addr, next, phys, __prot, pgtable_alloc, flags);
-- 
2.53.0.959.g497ff81fa9-goog



  parent reply	other threads:[~2026-03-20 15:00 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-20 14:59 [PATCH v3 00/13] arm64: Unmap linear alias of kernel data/bss Ard Biesheuvel
2026-03-20 14:59 ` [PATCH v3 01/13] arm64: Move the zero page to rodata Ard Biesheuvel
2026-03-20 14:59 ` [PATCH v3 02/13] arm64: mm: Preserve existing table mappings when mapping DRAM Ard Biesheuvel
2026-03-20 14:59 ` Ard Biesheuvel [this message]
2026-03-20 14:59 ` [PATCH v3 04/13] arm64: mm: Remove bogus stop condition from map_mem() loop Ard Biesheuvel
2026-03-20 14:59 ` [PATCH v3 05/13] arm64: mm: Drop redundant pgd_t* argument from map_mem() Ard Biesheuvel
2026-03-20 14:59 ` [PATCH v3 06/13] arm64: mm: Permit contiguous descriptors to be rewritten Ard Biesheuvel
2026-03-20 14:59 ` [PATCH v3 07/13] arm64: mm: Use hierarchical XN mapping for the fixmap Ard Biesheuvel
2026-03-20 14:59 ` [PATCH v3 08/13] arm64: kfence: Avoid NOMAP tricks when mapping the early pool Ard Biesheuvel
2026-03-20 14:59 ` [PATCH v3 09/13] arm64: mm: Permit contiguous attribute for preliminary mappings Ard Biesheuvel
2026-03-20 14:59 ` [PATCH v3 10/13] arm64: Move fixmap page tables to end of kernel image Ard Biesheuvel
2026-03-20 14:59 ` [PATCH v3 11/13] arm64: mm: Don't abuse memblock NOMAP to check for overlaps Ard Biesheuvel
2026-03-20 14:59 ` [PATCH v3 12/13] arm64: mm: Map the kernel data/bss read-only in the linear map Ard Biesheuvel
2026-03-20 14:59 ` [PATCH v3 13/13] arm64: mm: Unmap kernel data/bss entirely from " 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=20260320145934.2349881-18-ardb+git@google.com \
    --to=ardb+git@google.com \
    --cc=anshuman.khandual@arm.com \
    --cc=ardb@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=kees@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizprucka@google.com \
    --cc=mark.rutland@arm.com \
    --cc=ryan.roberts@arm.com \
    --cc=sethjenkins@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox