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] LoongArch: mm: Define DIRECT_MAP_PHYSMEM_END
Date: Tue, 11 Aug 2026 19:57:49 +0800 [thread overview]
Message-ID: <20260811115749.3465579-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 physical address
bits of the CPU (cpu_pabits, probed from CPUCFG1: 48 on
3A5000/3A6000, 47 on 3C6000, 40 on the 2K series).
The vmemmap window only covers physical space below 2^(cpu_pabits+1)
(VMEMMAP_SIZE), so on CPUs with fewer than 48 physical address bits
get_free_mem_region() may hand ZONE_DEVICE a region with no struct
page backing:
- On the 2K series the region returned at the top of the 48-bit
physical space is outside the vmemmap window; vmemmap_populate()
wraps the range around and maps it into low memory, silently
corrupting the page tables.
- On 3C6000 the vmemmap range of the region's last section used to
end exactly at 2^64 and wrap to 0, leaving vmemmap_populate() with
nothing to map, so memmap_init_zone_device() faulted while writing
struct page (reported with amdkfd on 6.16 [1]). Commit 2969b42c8f99
("LoongArch/mm: align vmemmap to maximal folio size") moved the
vmemmap base down by one PMD, which keeps that section in bounds on
current 3C6000 configs, but the 2K series is still affected and the
3C6000 case only holds for the current vmemmap layout.
Define DIRECT_MAP_PHYSMEM_END as (1ULL << cpu_pabits) - 1 so that
both searches stay within the vmemmap-covered physical space,
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>
---
arch/loongarch/include/asm/pgtable.h | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/loongarch/include/asm/pgtable.h b/arch/loongarch/include/asm/pgtable.h
index 223528c04d73..244931e4bc58 100644
--- a/arch/loongarch/include/asm/pgtable.h
+++ b/arch/loongarch/include/asm/pgtable.h
@@ -125,6 +125,13 @@ struct vm_area_struct;
#endif
+/* Needed to limit get_free_mem_region() */
+#if defined(CONFIG_FLATMEM) || defined(CONFIG_SPARSEMEM_VMEMMAP)
+#define DIRECT_MAP_PHYSMEM_END ((1ULL << cpu_pabits) - 1)
+#elif defined(CONFIG_SPARSEMEM)
+/* DIRECT_MAP_PHYSMEM_END is not limited by VA space assignment in this case */
+#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
next reply other threads:[~2026-08-11 11:59 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-11 11:57 Han Gao [this message]
2026-08-11 14:41 ` [PATCH] LoongArch: mm: Define DIRECT_MAP_PHYSMEM_END Huacai Chen
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=20260811115749.3465579-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