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

[Jinjiang Tu <tujinjiang@huawei.com>]

在 2026/1/16 2:12, Andrew Morton 写道:
> On Thu, 15 Jan 2026 18:10:51 +0100 "David Hildenbrand (Red Hat)" <david@kernel.org> wrote:
>
>> On 12/23/25 12:05, Jinjiang Tu wrote:
>>> 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 memory policy.
>>>
>>> When the cpuset of tasks changes, the mempolicy of the task is rebound by
>>> mpol_rebind_nodemask(). When MPOL_F_STATIC_NODES and MPOL_F_RELATIVE_NODES
>>> are both not set, the behaviour of rebinding should be same whenever
>>> MPOL_F_NUMA_BALANCING is set or not. So, when an application calls
>>> set_mempolicy() with MPOL_F_NUMA_BALANCING set but both MPOL_F_STATIC_NODES
>>> and MPOL_F_RELATIVE_NODES cleared, mempolicy.w.cpuset_mems_allowed should
>>> be set to cpuset_current_mems_allowed nodemask. However, in current
>>> implementation, mpol_store_user_nodemask() wrongly returns true, causing
>>> mempolicy->w.user_nodemask to be incorrectly set to the user-specified
>>> nodemask. Later, when the cpuset of the application changes,
>>> mpol_rebind_nodemask() ends up rebinding based on the user-specified
>>> nodemask rather than the cpuset_mems_allowed nodemask as intended.
>>>
>>> To fix this, only set mempolicy->w.user_nodemask to the user-specified
>>> nodemask if MPOL_F_STATIC_NODES or MPOL_F_RELATIVE_NODES is present.
>>>
>> ...
>>
>> I glimpsed over it and I think this is the right fix, thanks!
>>
>> Acked-by: David Hildenbrand (Red Hat) <david@kernel.org>
> Cool.  I decided this was "not for backporting", but the description of
> the userspace-visible runtime effects isn't very clear.  Jinjiang, can
> you please advise?

I agree don't backport this patch. Users can only see tasks binding to
wrong NUMA after it's cpuset changes.

Assuming there are 4 NUMA. task is binding to NUMA1 and it is in root cpuset.
Move the task to a cpuset whose cpuset.mems.effective is 0-1. The task should
still be binded to NUMA1, but is binded to NUMA0 wrongly.

>