From nobody Mon Feb 9 21:19:12 2026 Received: from mail-wm1-f74.google.com (mail-wm1-f74.google.com [209.85.128.74]) (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 E902A314A6D for ; Mon, 26 Jan 2026 09:27:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.74 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769419666; cv=none; b=RgJuyk3WWy2USq9dl27BT/rKzX8GfP2BufkjjoY876xCnTAwgZo2E34foeFRT2GnrUjcYR/1EQVj6CnlUrZ/86zQszeKCe+dz6qGFFuZqD+mGCXIjHVhAP8NHHdduhnkt8cDIdVH/B9l0gMpxuM3QDRJpB1MyxbFQ9tT6FhloR0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769419666; c=relaxed/simple; bh=fJbjU4lPsrWz5rpCDXB8BW3dRsBQgJaUJe7WcXD0bIQ=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=iW4iiHr0RS8M9iLapvOHvtnoCpJ3TE1ciPQPmDNlTMGXUKaaBa8ugUeQnb5R8Vn1iWf7ntzbtvcy8+YHeLJqrNc5F64JHf6G9PmPswGjbRKCuHaBvEqGWivbFAsKGO+MQ8BtIR0E+A4fAh4u8udU2Q7ji9T1RFw3ZilqDTqoAOk= 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=jgBqTZdS; arc=none smtp.client-ip=209.85.128.74 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="jgBqTZdS" Received: by mail-wm1-f74.google.com with SMTP id 5b1f17b1804b1-4802bb29400so76518815e9.0 for ; Mon, 26 Jan 2026 01:27:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1769419656; x=1770024456; 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=Q7QZsFTSOh849rOV6LRsDiE1RAQq4Vm6P1yBesuKlE0=; b=jgBqTZdSiYdvZ2BTP94nU2eax+aNYN+pTw+A4BeF1qblau5OvJ9/THTzI9qBXI1ySo syP9l6Eg5ufr8dt1sUDnblH+ern8pOiQW+3sqtX+m1SZ1zPvmFiT4H3f5eu876usDV1m FpbmtH5vjPqQWBS8o/xbeRM9g5wac2Eh4KjxyiOLSigRW1gFP3y+4mf+zD6zf5HhAD6V IVC7ZFfNkZN3QSACRAugiEJY8MIlwUj6bBqWHJW0RsiHtubXphTEavQGkrqCmW6zXnkX B+KJbatbf/Y3WuY0sQV86RfKwACO7iovfpWBKYy7YqHZ2Nuzx7ELenn9eyTHOPZ8RGcO T80g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769419656; x=1770024456; 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=Q7QZsFTSOh849rOV6LRsDiE1RAQq4Vm6P1yBesuKlE0=; b=k207fFeXxOnXAEwPd0jEb74bENs/vilUD4KnkxVLBVWkW6/2FqAb+RiCZIS3ifOSiF tt5y80Tff9fgFHuUXYhLS7lr8irc/0FVm+3YWZ2JDmOo5CvooRNvuUA0G/zLxLGvLqxe rVcBN8A6dDClhua52BhOogjcHH1+TYLYteJzJ2zoHOR3NLRsplKfMQustL8WP25vl+Xr oSqUsVsQvj+F8jt08TW1hX+UvOANAh2WCuZtXA5XRfi2jXZn7dXESkDx3V+TErYUI9Fr mibQlBdy3fXN+vAzWbuF5wQI96u75bb42xal/GEKT9Z/J/Hn6uDD1P6Q7YgGlqEkTL/o BTXw== X-Gm-Message-State: AOJu0YwhgtxdoJs3Jo7bigfnHDVjv2WgdfPa8nfM4Drok1LBU3wmoy8G rCoRIPdRvIJ0Ytt9o7CK3KDDnvhk4z57s7pjgb0T69G92RfYjdExxMXGpD6jk7kZXZPKlxPGZl/ hBCo+D6HJvDWhmvtFhGaMPNfbLLx/XOZKKfnKeeHjqBl1QRry6oBFn7qBn2LMHckaVuSVK33eAy JgxIx0cJujxs9YAdgE+d+5iA2K4/DeujvIIA== X-Received: from wmba22.prod.google.com ([2002:a05:600c:6dd6:b0:477:988a:7675]) (user=ardb job=prod-delivery.src-stubby-dispatcher) by 2002:a05:600c:4f43:b0:477:a54a:acba with SMTP id 5b1f17b1804b1-4805cf5f2b9mr73678575e9.17.1769419656035; Mon, 26 Jan 2026 01:27:36 -0800 (PST) Date: Mon, 26 Jan 2026 10:26:36 +0100 In-Reply-To: <20260126092630.1800589-12-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: <20260126092630.1800589-12-ardb+git@google.com> X-Developer-Key: i=ardb@kernel.org; a=openpgp; fpr=F43D03328115A198C90016883D200E9CA6329909 X-Developer-Signature: v=1; a=openpgp-sha256; l=2647; i=ardb@kernel.org; h=from:subject; bh=gTtNtodtCpnKfAIP/yDCxL7y5gOaP+fLKD5+ODcsG54=; b=owGbwMvMwCVmkMcZplerG8N4Wi2JIbPc2DP4c6/cvLuKPOWa81fyz1g4a51h+fLeU3u7soOsT nnqbnnfUcrCIMbFICumyCIw+++7nacnStU6z5KFmcPKBDKEgYtTACYS7cbwP99754VFqcZznjJ1 Xu8xP5ztEZb8nnMu44t3UrWSFo//lzEybHsbpvN4084X24Xl5myK0lpz6udkN5MTqXyGJY8/3xR y4QMA X-Mailer: git-send-email 2.52.0.457.g6b5491de43-goog Message-ID: <20260126092630.1800589-17-ardb+git@google.com> Subject: [PATCH v2 05/10] 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. Signed-off-by: Ard Biesheuvel Reviewed-by: Ryan Roberts --- 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 64d5f1d9cce9..cb2c4525e49a 100644 --- a/arch/arm64/include/asm/pgtable.h +++ b/arch/arm64/include/asm/pgtable.h @@ -224,6 +224,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 28cc3cda042c..d7faa98f427c 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.52.0.457.g6b5491de43-goog