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: <696566a1e228d_2071810076@dwillia2-mobl4.notmuch>
Date: Mon, 12 Jan 2026 13:24:49 -0800
From: <dan.j.williams@...el.com>
To: Yury Norov <ynorov@...dia.com>, Gregory Price <gourry@...rry.net>
CC: Balbir Singh <balbirs@...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>, <dan.j.williams@...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

Yury Norov wrote:
[..]
> > Dan Williams convinced me to go with N_PRIVATE, but this is really a
> > bikeshed topic
> 
> No it's not. To me (OK, an almost random reader in this discussion),
> N_PRIVATE is a pretty confusing name. It doesn't answer the question:
> private what? N_PRIVATE_MEMORY is better in that department, isn't?
> 
> But taking into account isolcpus, maybe N_ISOLMEM?
> 
> > - we could call it N_BOBERT until we find consensus.
> 
> Please give it the right name well describing the scope and purpose of
> the new restriction policy before moving forward.

...this is the definition of a bikeshed discussion, and bikeshed's are
important for building consensus. The argument for N_PRIVATE is with
respect to looking at this from the perspective of the other node_states
that do not have the _MEMORY designation particularly _ONLINE and the
fact that the other _MEMORY states implied zone implications whereas
N_PRIVATE can span zones.

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.