Re: [PATCH v2] cgroup/cpuset: use mems_allowed_seq when checking a policy nodemask

[Gregory Price <gourry@gourry.net>]

On Mon, Oct 19, 2026 at 06:41:50PM +0200, Vlastimil Babka (SUSE) wrote:
> On 10/19/26 18:21, Gregory Price (Meta) wrote:
> > A cpuset update changes the task's mems_allowed and rebinds its
> > mempolicy in separate steps under mems_allowed_seq, but the check
> > reads both without it.  This can cause a spurious numa placement
> > miss under some cpuset/mempolicy combinations.
> > 
> > A reader that loads one mask before the update and the other after
> > it can see a spurious empty intersection and drop the nodemask.
> > 
> > For example, a task with cpuset.mems={0} and MPOL_BIND={0}.  If the
> > cpuset moves to mems={1,2}, the policy is rebound to {1}.
> > 
> > The allocator can race and compare the old mems_allowed {0} against
> > the new policy {1} - which will result in a dropped nodemask and a
> > misplaced allocation on node 2.
> 
> And since this can have only performance implications and not cause a
> functional issue, we don't need Cc: stable.
> 
> (unlike violating a __GFP_THISNODE allocation which could be quite bad and
> has happened in the past)
> 

Agreed.

~Gregory