linux-kernel - Re: [PATCH v2 1/1] mm: numa_memblks: Identify the accurate NUMA ID of CFMW

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <696944eca1837_34d2a10056@dwillia2-mobl4.notmuch>
Date: Thu, 15 Jan 2026 11:50:04 -0800
From: <dan.j.williams@...el.com>
To: Andrew Morton <akpm@...ux-foundation.org>, Cui Chao
	<cuichao1753@...tium.com.cn>
CC: Jonathan Cameron <Jonathan.Cameron@...wei.com>, Mike Rapoport
	<rppt@...nel.org>, Wang Yinfeng <wangyinfeng@...tium.com.cn>,
	<linux-cxl@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<linux-mm@...ck.org>
Subject: Re: [PATCH v2 1/1] mm: numa_memblks: Identify the accurate NUMA ID of
 CFMW

Andrew Morton wrote:
> On Thu, 15 Jan 2026 17:43:02 +0800 Cui Chao <cuichao1753@...tium.com.cn> wrote:
> 
> > When a CXL RAM region is created in userspace, the memory capacity of 
> > the newly created region is not added to the CFMW-dedicated NUMA node. 
> > Instead, it is accumulated into an existing NUMA node (e.g., NUMA0 
> > containing RAM). This makes it impossible to clearly distinguish between 
> > the two types of memory, which may affect memory-tiering applications.
> > 
> 
> OK, thanks, I added this to the changelog.  Please retain it when
> sending v3.
> 
> What I'm actually looking for here are answers to the questions
> 
>   Should we backport this into -stable kernels and if so, why?
>   And if not, why not?
> 
> So a very complete description of the runtime effects really helps
> myself and others to decide which kernels to patch.  And it helps
> people to understand *why* we made that decision.
> 
> And sorry, but "may affect memory-tiering applications" isn't very
> complete!
> 
> So please, tell us how much our users are hurting from this and please
> make a recommendation on the backporting decision.
> 

To add on here, Cui, please describe which shipping hardware platforms
in the wild create physical address maps like this. For example, if this
is something that only occurs in QEMU configurations or similar, then
the urgency is low and it is debatable if Linux should even worry about
fixing it.

I know that x86 platforms typically do not do this. It is also
within the realm of possibility for platform firmware to fix. So in
addition to platform impact please also clarify why folks can not just
ask for a firmware update to get this fixed without updating their
kernel.