linux-kernel - Re: [PATCH v3] mm/vmscan: fix demotion targets checks in reclaim/demotion

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: <aVotEFFHwTPF_K1h@google.com>
Date: Sun, 4 Jan 2026 09:04:16 +0000
From: Bing Jiao <bingjiao@...gle.com>
To: Waiman Long <llong@...hat.com>
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org, gourry@...rry.net, hannes@...xchg.org,
	mhocko@...nel.org, roman.gushchin@...ux.dev, shakeel.butt@...ux.dev,
	muchun.song@...ux.dev, tj@...nel.org, mkoutny@...e.com,
	david@...nel.org, zhengqi.arch@...edance.com,
	lorenzo.stoakes@...cle.com, axelrasmussen@...gle.com,
	chenridong@...weicloud.com, yuanchu@...gle.com, weixugc@...gle.com,
	cgroups@...r.kernel.org
Subject: Re: [PATCH v3] mm/vmscan: fix demotion targets checks in
 reclaim/demotion

On Fri, Dec 26, 2025 at 03:24:29PM -0500, Waiman Long wrote:
> The nodemask_t type can be large depending on the setting of
> CONFIG_NODES_SHIFT. Passing a large data structure on stack may not be a
> good idea. You can return a pointer to nodemask_t instead. In that case, you
> will have a add a "const" qualifier to the return type to make sure that the
> node mask won't get accidentally modified. Alternatively, you can pass a
> nodemask_t pointer as an output parameter and copy out the nodemask_t data.
>
> The name "cpuset_node_get_allowed" doesn't fit the cpuset naming convention.
> There is a "cpuset_mems_allowed(struct task_struct *)" to return
> "mems_allowed" of a task. This new helper is for returning the mems_allowed
> defined in the cpuset. Perhaps we could just use
> "cpuset_nodes_allowed(struct cgroup *)".
>
> Cheers,
> Longman

Thank you for the explanation and suggestion.

I have updated v4, which updates the functions to filter out nodes
rather than returning mems_allowed. In v3, the caller need to declare
a temp nodemask_t to store mems_allowed and then intersect with
lower-tier nodemask, which is unnecessarily increase the stack size.

The function name is updated as "cpuset_nodes_filter_allowed".
Do you think it is still better to use "cpuset_nodes_allowed"
when doing the filtering thing?

Thanks,
Bing