Re: [PATCH v2] cgroup/cpuset: rebind mm mempolicy to effective_mems, not mems_allowed

[Gregory Price]

On Mon, Jun 15, 2026 at 10:08:51AM +0200, David Hildenbrand (Arm) wrote:
> On 6/14/26 15:25, Farhad Alemi wrote:
> > 
> > diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
> > --- a/kernel/cgroup/cpuset.c
> > +++ b/kernel/cgroup/cpuset.c
> > @@ -2649,7 +2649,7 @@ void cpuset_update_tasks_nodemask(struct cpuset *cs)
> > 
> >  		migrate = is_memory_migrate(cs);
> > 
> > -		mpol_rebind_mm(mm, &cs->mems_allowed);
> > +		mpol_rebind_mm(mm, &cs->effective_mems);
> 
> God this is confusing.
>

All interactions between mempolicy and cpuset are horrible and
confusing.  Much like Lorenzo's anon_vma work, I have to keep
notes on how this whole thing doesn't just spew SIGBUS constantly.

The short answer is: mempolicy is advisory and cpuset is strictly
followed - in a dispute cpuset wins... except for file backed memory,
then everyon loses and nothing is consistent.

> Naturally I wonder: Why are we not using "task->mems_allowed" (maybe cs vs. tsk
> was the original bug?), which is effectively just newmems?
>

Short answer: task->mems_allowed is protected by the task lock and we
don't hold the task lock for a foreign task (not-current) over mm
operations.

Long answer: Reasons and "Stop looking at the spaghetti, it's going to
break"

~Gregory