linux-kernel - Re: [PATCH v3 2/2] vmscan,cgroup: apply mems

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6e7806a7-9ffd-4c7c-b247-934b206088c7@redhat.com>
Date: Mon, 21 Apr 2025 20:35:15 -0400
From: Waiman Long <llong@...hat.com>
To: Gregory Price <gourry@...rry.net>, Shakeel Butt <shakeel.butt@...ux.dev>
Cc: Waiman Long <llong@...hat.com>, linux-mm@...ck.org,
 cgroups@...r.kernel.org, linux-kernel@...r.kernel.org, kernel-team@...a.com,
 hannes@...xchg.org, mhocko@...nel.org, roman.gushchin@...ux.dev,
 muchun.song@...ux.dev, tj@...nel.org, mkoutny@...e.com,
 akpm@...ux-foundation.org
Subject: Re: [PATCH v3 2/2] vmscan,cgroup: apply mems_effective to reclaim

On 4/21/25 7:58 PM, Gregory Price wrote:
> On Mon, Apr 21, 2025 at 04:15:49PM -0700, Shakeel Butt wrote:
>> On Mon, Apr 21, 2025 at 06:59:20PM -0400, Gregory Price wrote:
>>> On Mon, Apr 21, 2025 at 10:39:58AM -0700, Shakeel Butt wrote:
>>>> On Sat, Apr 19, 2025 at 08:14:29PM -0400, Waiman Long wrote:
>>>>> On 4/19/25 2:48 PM, Shakeel Butt wrote:
>>>>>> On Sat, Apr 19, 2025 at 01:38:24AM -0400, Gregory Price wrote:
>>>>>>> +bool cpuset_node_allowed(struct cgroup *cgroup, int nid)
>>>>>>> +{
>>>>>>> +	struct cgroup_subsys_state *css;
>>>>>>> +	unsigned long flags;
>>>>>>> +	struct cpuset *cs;
>>>>>>> +	bool allowed;
>>>>>>> +
>>>>>>> +	css = cgroup_get_e_css(cgroup, &cpuset_cgrp_subsys);
>>>>>>> +	if (!css)
>>>>>>> +		return true;
>>>>>>> +
>>>>>>> +	cs = container_of(css, struct cpuset, css);
>>>>>>> +	spin_lock_irqsave(&callback_lock, flags);
>>>>>> Do we really need callback_lock here? We are not modifying and I am
>>>>>> wondering if simple rcu read lock is enough here (similar to
>>>>>> update_nodemasks_hier() where parent's effective_mems is accessed within
>>>>>> rcu read lock).
>>>>> The callback_lock is required to ensure the stability of the effective_mems
>>>>> which may be in the process of being changed if not taken.
>>>> Stability in what sense? effective_mems will not get freed under us
>>>> here or is there a chance for corrupted read here? node_isset() and
>>>> nodes_empty() seems atomic. What's the worst that can happen without
>>>> callback_lock?
>>> Fairly sure nodes_empty is not atomic, it's a bitmap search.
>> For bitmaps smaller than 64 bits, it seems atomic and MAX_NUMNODES seems
>> smaller than 64 in all the archs.
> Unfortunately, it's config-defined on (NODES_SHIFT) and the max is 1024.
Actually, it is nr_node_ids that control how many reads are needed to 
scan the complete node mask, not CONFIG_NODE_SHIFT.
>
> Is there an argument here for ignoring v1 and just doing the bit-check
> without the lock?  Is there an easy ifdef way for us to just return true
> if it's v1?

Your current patch is ignoring v1 as css will be NULL. It only works for 
v2 with a unified hierarchy unless some users explicitly force cpuset 
and memcg v1 to be in the same hierarchy. You can certainly ignore v1 by 
using cpuset_v2() check.

Cheers,
Longman

~Gregory