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] [thread-next>] [day] [month] [year] [list]

Message-ID: <aYXtHa4Y2y_5xgcS@gourry-fedora-PF4VCD3F>
Date: Fri, 6 Feb 2026 08:31:09 -0500
From: Gregory Price <gourry@...rry.net>
To: Jonathan Cameron <jonathan.cameron@...wei.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
	Cui Chao <cuichao1753@...tium.com.cn>, dan.j.williams@...el.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, qemu-devel@...gnu.org
Subject: Re: [PATCH v2 1/1] mm: numa_memblks: Identify the accurate NUMA ID
 of CFMW

On Fri, Feb 06, 2026 at 11:03:05AM +0000, Jonathan Cameron wrote:
> On Thu, 5 Feb 2026 18:10:55 -0500
> Gregory Price <gourry@...rry.net> wrote:
> 
> I disagree. There is nothing in the specification to say it should do that and
> we have very intentionally not done so in QEMU - this is far from the first
> time this has come up!. We won't be doing so any time soon unless someone
> convinces me with clear spec references and tight reasoning for why it is the
> right thing to do.
> 

Interestingly I've had this exact conversation - in reverse - with other
platform folks, who think CFMWS w/o SRAT is broken.  It was a zealous
enough opinion that I may have over-indexed on it (plus i've read the
numa mapping code and making this more dynamic seems difficult).

> This configuration reflects the pre hotplug / early CXL deployment
> situation. Now we have proper support in Linux we have moved beyond that.
> We do need to solve the dynamic NUMA node cases though and I'm hoping your
> current work will make that a bit easier.

If we want flexibility to ship HPAs around to different nodes at
runtime, that might cause issues. The page-to-nid / pa-to-nid mapping
code is somewhat expected to be immutable after __init, so there could
be nasty assumptions sprinkled all over the kernel.

That will take some time.
---

Andrew if Jonathan is good with it then with changelog updates this can
go in, otherwise I don't think this warrants a backport or anything.

~Gregory