linux-kernel - Re: [PATCH v4 00/11] mempolicy2, mbind2, and weighted interleave

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: <ZYqAHesihJ+XCCyy@memverge.com>
Date: Tue, 26 Dec 2023 02:26:21 -0500
From: Gregory Price <gregory.price@...verge.com>
To: "Huang, Ying" <ying.huang@...el.com>
Cc: Gregory Price <gourry.memverge@...il.com>, linux-mm@...ck.org,
	linux-doc@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-api@...r.kernel.org,
	x86@...nel.org, akpm@...ux-foundation.org, arnd@...db.de,
	tglx@...utronix.de, luto@...nel.org, mingo@...hat.com, bp@...en8.de,
	dave.hansen@...ux.intel.com, hpa@...or.com, mhocko@...nel.org,
	tj@...nel.org, corbet@....net, rakie.kim@...com,
	hyeongtak.ji@...com, honggyu.kim@...com, vtavarespetr@...ron.com,
	peterz@...radead.org, jgroves@...ron.com, ravis.opensrc@...ron.com,
	sthanneeru@...ron.com, emirakhur@...ron.com, Hasan.Maruf@....com,
	seungjun.ha@...sung.com, Johannes Weiner <hannes@...xchg.org>,
	Hasan Al Maruf <hasanalmaruf@...com>, Hao Wang <haowang3@...com>,
	Dan Williams <dan.j.williams@...el.com>,
	Michal Hocko <mhocko@...e.com>,
	Zhongkun He <hezhongkun.hzk@...edance.com>,
	Frank van der Linden <fvdl@...gle.com>,
	John Groves <john@...alactic.com>,
	Jonathan Cameron <Jonathan.Cameron@...wei.com>
Subject: Re: [PATCH v4 00/11] mempolicy2, mbind2, and weighted interleave

On Wed, Dec 20, 2023 at 10:27:06AM +0800, Huang, Ying wrote:
> Gregory Price <gregory.price@...verge.com> writes:
> 
> > Assuming we remove policy_node altogether... do we still break up the
> > set/get interface into separate structures to avoid this in the future?
> 
> I have no much experience at ABI definition.  So, I want to get guidance
> from more experienced people on this.
> 
> Is it good to implement all functionality of get_mempolicy() with
> get_mempolicy2(), so we can deprecate get_mempolicy() and remove it
> finally?  So, users don't need to use 2 similar syscalls?
> 
> And, IIUC, we will not get policy_node, addr_node, and policy config at
> the same time, is it better to use a union instead of struct in
> get_mempolicy2()?
> 

We discussed using flags to change the operation of mempolicy earlier
and it was expressed that multiplexing syscalls via flags is no longer
a preferred design because it increases complexity in the long term.

The mems_allowed extension to get_mempolicy() is basically this kind of
multiplexing.  So ultimately I think it better to simply remove that
functionality from get_mempolicy2().

Further: it's not even technically *part* of mempolicy, it's part of
cpusets, and is accessible via sysfs through some combination of
cpuset.mems and cpuset.mems.effective.

So the mems_allowed part of get_mempolicy() has already been deprecated
in that way.  Doesn't seem worth it to add it to mempolicy2.

The `policy_node` is more of a question as to whether it's even useful.
Right now it only applies to interleave policies... but it's also
insanely racey.  The moment you pluck the next interleave target, it's
liable to change.  I don't know how anyone would even use this.

If we drop it, we can alway add it back in with an extension if someone
actually has a use-case for it and we decide to fully deprecate
get_mempolicy() (which seems unlikely, btw).

In either case, the extension I made allows get_mempolicy() to be used
to fetch policy_node via the original method, for new policies, so that
would cover it if anyone is actually using it.

~Gregory