From: Han Gao <gaohan@iscas.ac.cn>
To: Huacai Chen <chenhuacai@kernel.org>,
WANG Xuerui <kernel@xen0n.name>, Paul Walmsley <pjw@kernel.org>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Alexandre Ghiti <alex@ghiti.fr>,
Andrew Morton <akpm@linux-foundation.org>,
"Mike Rapoport (Microsoft)" <rppt@kernel.org>,
Tianyang Zhang <zhangtianyang@loongson.cn>,
Magnus Lindholm <linmag7@gmail.com>,
Kiryl Shutsemau <kas@kernel.org>, Han Gao <gaohan@iscas.ac.cn>,
Hongchen Zhang <zhanghongchen@loongson.cn>,
WangYuli <wangyuli@aosc.io>, "Mingcong Bai" <jeffbai@aosc.io>,
"Zhang Yuhao" <xinmu@xinmu.moe>,
"Kexy Biscuit" <kexybiscuit@aosc.io>
Cc: loongarch@lists.linux.dev, linux-kernel@vger.kernel.org,
linux-riscv@lists.infradead.org, Han Gao <rabenda.cn@gmail.com>,
stable@vger.kernel.org
Subject: [PATCH v2] LoongArch: mm: Define DIRECT_MAP_PHYSMEM_END
Date: Tue, 11 Aug 2026 23:43:06 +0800 [thread overview]
Message-ID: <20260811154306.3764527-1-gaohan@iscas.ac.cn> (raw)
get_free_mem_region() and mhp_get_pluggable_range() bound their
search to DIRECT_MAP_PHYSMEM_END. LoongArch does not define it, so
the fallback in include/linux/mm.h applies: under
CONFIG_SPARSEMEM_VMEMMAP it is (1ULL << MAX_PHYSMEM_BITS) - 1, a
compile-time constant that does not adapt to the CPU's physical
address bits (cpu_pabits, probed from CPUCFG1).
The vmemmap window only covers physical space below 2^(cpu_pabits+1)
(VMEMMAP_SIZE), so on CPUs with fewer physical address bits than
MAX_PHYSMEM_BITS the fallback allows get_free_mem_region() to return
a ZONE_DEVICE region outside the vmemmap window;
vmemmap_populate() then wraps the memmap range around and maps it
into low memory, silently corrupting the page tables. The same
search also picked the top-of-address-space region that crashed
memmap_init_zone_device() with amdkfd on 3C6000 in 6.16 [1];
commit 2969b42c8f99 ("LoongArch/mm: align vmemmap to maximal folio
size") keeps that region in bounds on current 3C6000 configs, but
CPUs with smaller cpu_pabits (e.g. the 2K series) are still
affected.
Define DIRECT_MAP_PHYSMEM_END as the vmemmap-covered physical
range, (1ULL << (cpu_pabits + 1)) - 1, capped at
(1ULL << MAX_PHYSMEM_BITS) - 1 under CONFIG_SPARSEMEM, mirroring
commit f3336b48cf9d ("riscv: mm: Define DIRECT_MAP_PHYSMEM_END").
[1] https://lore.kernel.org/amd-gfx/20250814032153.227285-1-jeffbai@aosc.io/
Cc: stable@vger.kernel.org # v6.13+
Signed-off-by: Han Gao <gaohan@iscas.ac.cn>
---
Changes in v2:
- Redefine DIRECT_MAP_PHYSMEM_END as the vmemmap-covered range
(1ULL << (cpu_pabits + 1)) - 1, capped at
(1ULL << MAX_PHYSMEM_BITS) - 1 under CONFIG_SPARSEMEM, per Huacai
Chen's review (the previous (1ULL << cpu_pabits) - 1 wrongly
limits CPUs with 48-bit physical addresses).
- Note that 3C6000 has 48-bit physical addresses as well.
- v1: https://lore.kernel.org/all/20260811115749.3465579-1-gaohan@iscas.ac.cn/
arch/loongarch/include/asm/pgtable.h | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/loongarch/include/asm/pgtable.h b/arch/loongarch/include/asm/pgtable.h
index 223528c04d73..8395aea209b5 100644
--- a/arch/loongarch/include/asm/pgtable.h
+++ b/arch/loongarch/include/asm/pgtable.h
@@ -125,6 +125,14 @@ struct vm_area_struct;
#endif
+/* Needed to limit get_free_mem_region() */
+#ifndef CONFIG_SPARSEMEM
+#define DIRECT_MAP_PHYSMEM_END ((1ULL << (cpu_pabits + 1)) - 1)
+#else
+#define DIRECT_MAP_PHYSMEM_END \
+ min((1ULL << (cpu_pabits + 1)) - 1, (1ULL << MAX_PHYSMEM_BITS) - 1)
+#endif
+
#define ptep_get(ptep) READ_ONCE(*(ptep))
#define pmdp_get(pmdp) READ_ONCE(*(pmdp))
--
2.47.3
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
reply other threads:[~2026-08-11 15:43 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20260811154306.3764527-1-gaohan@iscas.ac.cn \
--to=gaohan@iscas.ac.cn \
--cc=akpm@linux-foundation.org \
--cc=alex@ghiti.fr \
--cc=aou@eecs.berkeley.edu \
--cc=chenhuacai@kernel.org \
--cc=jeffbai@aosc.io \
--cc=kas@kernel.org \
--cc=kernel@xen0n.name \
--cc=kexybiscuit@aosc.io \
--cc=linmag7@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=loongarch@lists.linux.dev \
--cc=palmer@dabbelt.com \
--cc=pjw@kernel.org \
--cc=rabenda.cn@gmail.com \
--cc=rppt@kernel.org \
--cc=stable@vger.kernel.org \
--cc=wangyuli@aosc.io \
--cc=xinmu@xinmu.moe \
--cc=zhanghongchen@loongson.cn \
--cc=zhangtianyang@loongson.cn \
/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