Linux-RISC-V Archive on lore.kernel.org
 help / color / mirror / Atom feed
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

             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