linux-kernel - Re: [RFC PATCH v3 0/8] mm,numa: N_PRIVATE node isolation for device-managed memory

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: <69659d418650a_207181009a@dwillia2-mobl4.notmuch>
Date: Mon, 12 Jan 2026 17:17:53 -0800
From: <dan.j.williams@...el.com>
To: Gregory Price <gourry@...rry.net>, Balbir Singh <balbirs@...dia.com>
CC: <dan.j.williams@...el.com>, Yury Norov <ynorov@...dia.com>,
	<linux-mm@...ck.org>, <cgroups@...r.kernel.org>, <linux-cxl@...r.kernel.org>,
	<linux-doc@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<linux-fsdevel@...r.kernel.org>, <kernel-team@...a.com>,
	<longman@...hat.com>, <tj@...nel.org>, <hannes@...xchg.org>,
	<mkoutny@...e.com>, <corbet@....net>, <gregkh@...uxfoundation.org>,
	<rafael@...nel.org>, <dakr@...nel.org>, <dave@...olabs.net>,
	<jonathan.cameron@...wei.com>, <dave.jiang@...el.com>,
	<alison.schofield@...el.com>, <vishal.l.verma@...el.com>,
	<ira.weiny@...el.com>, <akpm@...ux-foundation.org>, <vbabka@...e.cz>,
	<surenb@...gle.com>, <mhocko@...e.com>, <jackmanb@...gle.com>,
	<ziy@...dia.com>, <david@...nel.org>, <lorenzo.stoakes@...cle.com>,
	<Liam.Howlett@...cle.com>, <rppt@...nel.org>, <axelrasmussen@...gle.com>,
	<yuanchu@...gle.com>, <weixugc@...gle.com>, <yury.norov@...il.com>,
	<linux@...musvillemoes.dk>, <rientjes@...gle.com>, <shakeel.butt@...ux.dev>,
	<chrisl@...nel.org>, <kasong@...cent.com>, <shikemeng@...weicloud.com>,
	<nphamcs@...il.com>, <bhe@...hat.com>, <baohua@...nel.org>,
	<yosry.ahmed@...ux.dev>, <chengming.zhou@...ux.dev>,
	<roman.gushchin@...ux.dev>, <muchun.song@...ux.dev>, <osalvador@...e.de>,
	<matthew.brost@...el.com>, <joshua.hahnjy@...il.com>, <rakie.kim@...com>,
	<byungchul@...com>, <ying.huang@...ux.alibaba.com>, <apopple@...dia.com>,
	<cl@...two.org>, <harry.yoo@...cle.com>, <zhengqi.arch@...edance.com>
Subject: Re: [RFC PATCH v3 0/8] mm,numa: N_PRIVATE node isolation for
 device-managed memory

Gregory Price wrote:
> On Tue, Jan 13, 2026 at 09:54:32AM +1100, Balbir Singh wrote:
> > On 1/13/26 08:10, dan.j.williams@...el.com wrote:
> > > Balbir Singh wrote:
> > > [..]
> > >>> I agree with Gregory the name does not matter as much as the
> > >>> documentation explaining what the name means. I am ok if others do not
> > >>> sign onto the rationale for why not include _MEMORY, but lets capture
> > >>> something that tries to clarify that this is a unique node state that
> > >>> can have "all of the above" memory types relative to the existing
> > >>> _MEMORY states.
> > >>>
> > >>
> > >> To me, N_ is a common prefix, we do have N_HIGH_MEMORY, N_NORMAL_MEMORY.
> > >> N_PRIVATE does not tell me if it's CPU or memory related.
> > > 
> > > True that confusion about whether N_PRIVATE can apply to CPUs is there.
> > > How about split the difference and call this:
> > > 
> > >     N_MEM_PRIVATE
> > > 
> > > To make it both distinct from _MEMORY and _HIGH_MEMORY which describe
> > > ZONE limitations and distinct from N_CPU.
> > 
> > I'd be open to that name, how about N_MEMORY_PRIVATE? So then N_MEMORY
> > becomes (N_MEMORY_PUBLIC by default)
> >
> 
> N_MEMORY_PUBLIC is forcing everyone else to change for the sake a new
> feature, better to keep it N_MEM[ORY]_PRIVATE if anything

I think what Balbir is saying is that the _PUBLIC is implied and can be
omitted. It is true that N_MEMORY[_PUBLIC] already indicates multi-zone
support. So N_MEMORY_PRIVATE makes sense to me as something that it is
distinct from N_{HIGH,NORMAL}_MEMORY which are subsets of N_MEMORY.
Distinct to prompt "go read the documentation to figure out why this
thing looks not like the others".