From nobody Fri Apr 3 08:27:07 2026 Received: from mail-wm1-f73.google.com (mail-wm1-f73.google.com [209.85.128.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 500DE3C4565 for ; Fri, 20 Mar 2026 15:00:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.73 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774018808; cv=none; b=t9mCyW3cE0w2YYQq4YMqcI7rD/Mm6+I0x3XJHEFlECkYQFPfilXpJFudVrit/YVnj2ti8b4DZXTIbMcFJNtf6tkIiYQYxxxIhGLBxpqOMPcLgOzymoKfAqBWmyKutaSXnHryalyaJASZ+zp8x0fxVONHfmRJbRl4s7pHBvTJCpI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774018808; c=relaxed/simple; bh=lPdFgqEE8oXtZZQFrMk9kg0bR0AvOvClQoLr8bca0gQ=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=orlPC3TomoCIiPEoSTbOCE1mmU4u9EmptWZFtMa0yMoNv3hEzk1J20+bwnj78nMtcJrw8ERPOy+8ewPr7UBK6hinc238/ug6Iz4QCJZaT2xdgH1fEzhEnL7Y8OOqwz2DOGTuhXeLChxvyjoySU6zRn0eDoRgV8K0BrGcvyhMUTU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--ardb.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=nTaW9sce; arc=none smtp.client-ip=209.85.128.73 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--ardb.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="nTaW9sce" Received: by mail-wm1-f73.google.com with SMTP id 5b1f17b1804b1-485c45885e6so30905175e9.0 for ; Fri, 20 Mar 2026 08:00:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1774018801; x=1774623601; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=neRKNeSqpvJnLheaedaHzSD+GAHs81oovoUYepc/lXo=; b=nTaW9sceDNi5sBhx9ePkdCY1jF6JS3TEFAaC+gmRnb0TUKgMHg0PSh4W0a7/Bl/ctk ismke/OvyabB9ImX6GId6zRJpzWzttmZslnYKhV3M1a9dL07b1loas20I+34Gp4uuXwi Ap2VnHFTMoCIh8ACn0llXQaojVUBl4h+AZWgRREqoaXjfo2w1e40m7URxOFtpYVWPAuz e5reEy9MGv+bvUZUwz4zjfOwv8SC6d9gIMZTmHazQSbx7OXA4E9ZHMlfHjmxdsr3YBgg x01mz/gvSgsV7HT5In692s7MP8DGeG2LJJloEkK6x3ieA57TF+5B8FFYWK0K7E/UkwEp kXPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774018801; x=1774623601; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=neRKNeSqpvJnLheaedaHzSD+GAHs81oovoUYepc/lXo=; b=aO4wedPTCqRdBLz80x6KQDHbk+SkLPgLYPJxgVszFmnCoIaJYZG6pCx6dI9XM0e9i7 KfRGgDNWEnGBHubraT/N5g1GIYmzp6ZOG5RaU7Vc32HIG+jEHWJRCEBCxMNk6jrgTRkn ht2a3qqO8PgbUmPZBOD2OLeUdXRtU6Dzc4Rl7XWg2rek2qnMxbzcOFdG8xi4qmuAclJ2 XmMyu/9F05l/IIfxj180PxA4r98vfHc+4nfEnbxFim+a4SEkc59kzgYSblwuE6cOh6HU N8NGGF/V99xUTPtyPTff8e1NngOMBxhI2q9T1AQUwt7oRmlUhoFRR3R7MXDkkHU0G49I 5uxg== X-Gm-Message-State: AOJu0YzBZeA1yTeKtlNuN5rrYB2Vc+t7k83y6D5NIbqcuZwd4B1VLYnF RMpWsGpOGxdW8vQOiRTCFokG+CLg7fmejk975E2gs1Y3X7dfy8TC5NyGCfGSzyI/TEfR8glfzXS xLTwvAN4DvnolG56rJeW6KRWkfPugtGok6VCFjsSQNaPJYxkg3f+rL7DD0EDI2lwu1YZphOOjCO AaGfeSnaZPfu9+lCQoCqt2g21gnV4zOLyRaQ== X-Received: from wmlf18.prod.google.com ([2002:a7b:c8d2:0:b0:483:7a98:f072]) (user=ardb job=prod-delivery.src-stubby-dispatcher) by 2002:a05:600c:c48f:b0:485:b6dd:5066 with SMTP id 5b1f17b1804b1-486febb6014mr50607075e9.7.1774018800895; Fri, 20 Mar 2026 08:00:00 -0700 (PDT) Date: Fri, 20 Mar 2026 15:59:38 +0100 In-Reply-To: <20260320145934.2349881-15-ardb+git@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260320145934.2349881-15-ardb+git@google.com> X-Developer-Key: i=ardb@kernel.org; a=openpgp; fpr=F43D03328115A198C90016883D200E9CA6329909 X-Developer-Signature: v=1; a=openpgp-sha256; l=2697; i=ardb@kernel.org; h=from:subject; bh=TuswSFvpHM3Mr71nHK8iSkeQ2cBVxUsQsRsYd8yRYuI=; b=owGbwMvMwCVmkMcZplerG8N4Wi2JIXNvwu1QGc17/9r21omerLN+XHuGaVdo3enIhfHzJrH+i Or3aT3YUcrCIMbFICumyCIw+++7nacnStU6z5KFmcPKBDKEgYtTACYi6sTIcHtC4bWNE784v+yf /Pguw5T9ay//LWk3CFO9K+rmvuEK60ZGhoXzPlp/tZjoyPd26e7G850npbKnlJ10WfX05sOIqul HbzIAAA== X-Mailer: git-send-email 2.53.0.959.g497ff81fa9-goog Message-ID: <20260320145934.2349881-18-ardb+git@google.com> Subject: [PATCH v3 03/13] arm64: mm: Preserve non-contiguous descriptors when mapping DRAM From: Ard Biesheuvel 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 , Ryan Roberts , Anshuman Khandual , Liz Prucka , Seth Jenkins , Kees Cook , linux-hardening@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ard Biesheuvel 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 Signed-off-by: Ard Biesheuvel --- 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/pgta= ble.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 p= hys) * 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 lo= ng addr, =20 /* use a contiguous mapping if the range is suitably aligned */ if ((((addr | next | phys) & ~CONT_PTE_MASK) =3D=3D 0) && - (flags & NO_CONT_MAPPINGS) =3D=3D 0) + (flags & NO_CONT_MAPPINGS) =3D=3D 0 && + !pte_valid_noncont(__ptep_get(ptep))) __prot =3D __pgprot(pgprot_val(prot) | PTE_CONT); =20 init_pte(ptep, addr, next, phys, __prot); @@ -330,7 +331,8 @@ static int alloc_init_cont_pmd(pud_t *pudp, unsigned lo= ng addr, =20 /* use a contiguous mapping if the range is suitably aligned */ if ((((addr | next | phys) & ~CONT_PMD_MASK) =3D=3D 0) && - (flags & NO_CONT_MAPPINGS) =3D=3D 0) + (flags & NO_CONT_MAPPINGS) =3D=3D 0 && + !pte_valid_noncont(pmd_pte(READ_ONCE(*pmdp)))) __prot =3D __pgprot(pgprot_val(prot) | PTE_CONT); =20 ret =3D init_pmd(pmdp, addr, next, phys, __prot, pgtable_alloc, flags); --=20 2.53.0.959.g497ff81fa9-goog