[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7dtp6v5evpz5sdevwrexhwcdtl5enczssvuepkib2oiaexk3oo@ranij7pskrhe>
Date: Mon, 21 Apr 2025 10:39:58 -0700
From: Shakeel Butt <shakeel.butt@...ux.dev>
To: Waiman Long <llong@...hat.com>
Cc: Gregory Price <gourry@...rry.net>, 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 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?
Powered by blists - more mailing lists