[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ded4c23a-fecf-40ff-94ac-0d121a421297@redhat.com>
Date: Tue, 22 Apr 2025 15:57:57 -0400
From: Waiman Long <llong@...hat.com>
To: Gregory Price <gourry@...rry.net>, linux-mm@...ck.org
Cc: cgroups@...r.kernel.org, linux-kernel@...r.kernel.org,
kernel-team@...a.com, hannes@...xchg.org, mhocko@...nel.org,
roman.gushchin@...ux.dev, shakeel.butt@...ux.dev, muchun.song@...ux.dev,
tj@...nel.org, mkoutny@...e.com, akpm@...ux-foundation.org
Subject: Re: [PATCH] cpuset: relax locking on cpuset_node_allowed
On 4/22/25 12:30 AM, Gregory Price wrote:
> The cgroup_get_e_css reference protects the css->effective_mems, and
> calls of this interface would be subject to the same race conditions
> associated with a non-atomic access to cs->effective_mems.
>
> So while this interface cannot make strong guarantees of correctness,
> it can therefore avoid taking a global or rcu_read_lock for performance.
>
> Drop the rcu_read_lock from cpuset_node_allowed.
>
> Suggested-by: Shakeel Butt <shakeel.butt@...ux.dev>
> Suggested-by: Waiman Long <longman@...hat.com>
> Signed-off-by: Gregory Price <gourry@...rry.net>
> ---
> kernel/cgroup/cpuset.c | 14 ++++++++++++--
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
> index c52348bfd5db..1dc41758c62c 100644
> --- a/kernel/cgroup/cpuset.c
> +++ b/kernel/cgroup/cpuset.c
> @@ -4181,10 +4181,20 @@ bool cpuset_node_allowed(struct cgroup *cgroup, int nid)
> if (!css)
> return true;
>
> + /*
> + * Normally, accessing effective_mems would require the cpuset_mutex
> + * or RCU read lock - but node_isset is atomic and the reference
> + * taken via cgroup_get_e_css is sufficient to protect css.
> + *
> + * Since this interface is intended for use by migration paths, we
> + * relax locking here to avoid taking global locks - while accepting
> + * there may be rare scenarios where the result may be innaccurate.
> + *
> + * Reclaim and migration are subject to these same race conditions, and
> + * cannot make strong isolation guarantees, so this is acceptable.
> + */
> cs = container_of(css, struct cpuset, css);
> - rcu_read_lock();
> allowed = node_isset(nid, cs->effective_mems);
> - rcu_read_unlock();
> css_put(css);
> return allowed;
> }
Except for mislabeling RCU read lock instead of callback_lock as pointed
out by Johannes, the change looks good to me.
Reviewed-by: Waiman Long <longman@...hat.com>
Powered by blists - more mailing lists