Re: [PATCH] mm/mempolicy: fix mpol_rebind_nodemask() for MPOL_F_NUMA_BALANCING

[Andrew Morton <akpm@linux-foundation.org>]

On Sat, 13 Dec 2025 16:29:11 +0800 Jinjiang Tu <tujinjiang@huawei.com> wrote:

> When mempolicy is rebound due to the process moves to a different cpuset
> context, or the set of nodes allowed by current cpuset context changes,
> mpol_rebind_nodemask() remaps the nodemask according to the old and new
> cpuset_mems_allowed by default. So, use mempolicy.w.cpuset_mems_allowed
> to store the old nodemask allowed by cpuset.
> 
> MPOL_F_STATIC_NODES suppresses the node remap and intersects the user's
> passed nodemask and nodes allowed by new cpuset context.
> For MPOL_F_RELATIVE_NODES, the user's passed nodemask means node IDs that
> are relative to the set of node IDs allowed by the process's current
> cpuset. So, use mempolicy.w.user_nodemask to store the user's passed
> nodemask.
> 
> commit bda420b98505 ("numa balancing: migrate on fault among multiple
> bound nodes") adds new flag MPOL_F_NUMA_BALANCING to enable NUMA balancing
> for MPOL_BIND, the behaviour of rebinding should be same with default
> befaviour. However, mpol_store_user_nodemask() returns true for
> MPOL_F_NUMA_BALANCING, leading to mempolicy.w.cpuset_mems_allowed stores
> the user's passed nodemask instead of cpuset_current_mems_allowed, and
> mpol_rebind_nodemask() remaps wrongly.

Thanks.

I find the changelog hard to follow, unfortunately.  It's odd that the
problem description comes in the final paragraph!

I cheekily changed that and then fed the text into Gemini, which
I think helped. What do you think of the below?

I won't merge the patch at this time - I'll await reviewer input.


## Bug Fix: Corrected `MPOL_BIND` Rebinding with `MPOL_F_NUMA_BALANCING`

### Problem

The commit `bda420b98505` ("numa balancing: migrate on fault among
multiple bound nodes") introduced the new flag
**`MPOL_F_NUMA_BALANCING`** to enable NUMA balancing for the
**`MPOL_BIND`** memory policy.

The intended behavior was for the rebinding logic to remain the same as
the default `MPOL_BIND` behavior.  However, the function
`mpol_store_user_nodemask()` was incorrectly returning `true` for
policies containing `MPOL_F_NUMA_BALANCING`.

This led to a bug where:

1.  `mempolicy.w.cpuset_mems_allowed` stored the **user's passed
    nodemask** instead of the actual nodemask allowed by the current
    cpuset context (`cpuset_current_mems_allowed`).

2.  Consequently, **`mpol_rebind_nodemask()` performed incorrect
    remapping** when the mempolicy was rebound.

### Analysis of Correct Rebinding Logic

When a memory policy is rebound (e.g., because the process moves to a
different cpuset context, or the allowed nodes within the current
cpuset change), `mpol_rebind_nodemask()`, by default, remaps the
policy's nodemask based on the transition between the **old** and
**new** `cpuset_mems_allowed` sets.

To support this mechanism correctly, `mempolicy.w.cpuset_mems_allowed`
**must store the old nodemask allowed by the cpuset** before the
transition.

### Context for Other Flags

* **`MPOL_F_STATIC_NODES`**: This flag suppresses the node remap and
  simply intersects the user's passed nodemask with the nodes allowed
  by the new cpuset context.

* **`MPOL_F_RELATIVE_NODES`**: For this policy, the user's passed
  nodemask represents node IDs **relative** to the set of node IDs
  allowed by the process's current cpuset.  Therefore,
  `mempolicy.w.user_nodemask` is correctly used to store the user's
  original relative nodemask.

### Proposed Fix

Ensure that `mpol_store_user_nodemask()` handles
`MPOL_F_NUMA_BALANCING` correctly so that
`mempolicy.w.cpuset_mems_allowed` stores the correct cpuset-allowed
nodemask, thereby restoring the proper remapping behavior in
`mpol_rebind_nodemask()`.