[PATCH] mm/mempolicy: ignore a bind policy whose nodes have no memory

[PATCH] mm/mempolicy: ignore a bind policy whose nodes have no memory

[Gregory Price (Meta)]

apply_policy_zone() assumes that policy->nodes intersects N_MEMORY, so
it reads a bind policy with no N_HIGH_MEMORY node as movable-only.

On systems with CONFIG_CPUSETS=n, nothing rebinds policies when memory
is removed, so offlining all memory on the nodes a bind policy names
leaves it with none. The policy is then treated as movable-only, and
movable allocations are restricted to nodes without memory.

This results in allocations failures, a VM_FAULT_OOM leak, and then
an infinitely retrying fault that hangs the process.

  page allocation failure: order:0, mode:0x140dca ... nodemask=2
  Huh VM_FAULT_OOM leaked out to the #PF handler. Retrying PF

Ignore a bind policy whose nodes have no memory. policy_nodemask()
already ignores a bind policy that does not intersect the cpuset.
This covers hugetlb's policy_mbind_nodemask() as well.

If the nodes regain memory, the policy applies again.

CPUSETS=n with HOTREMOVE=y is unlikely a common configuration, so this
isn't marked for stable.

Signed-off-by: Gregory Price (Meta) <gourry@gourry.net>
---
 mm/mempolicy.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index ca7e744727b1..5dc2d7ef1544 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -2096,6 +2096,10 @@ bool apply_policy_zone(struct mempolicy *policy, enum zone_type zone)
 
 	BUG_ON(dynamic_policy_zone == ZONE_MOVABLE);
 
+	/* Memory hot-remove can leave policy->nodes without memory. */
+	if (!nodes_intersects(policy->nodes, node_states[N_MEMORY]))
+		return false;
+
 	/*
 	 * if policy->nodes has movable memory only,
 	 * we apply policy when gfp_zone(gfp) = ZONE_MOVABLE only.
-- 
2.56.0

Re: [PATCH] mm/mempolicy: ignore a bind policy whose nodes have no memory

[Zi Yan]

On 13 Nov 2026, at 14:26, Gregory Price (Meta) wrote:

> apply_policy_zone() assumes that policy->nodes intersects N_MEMORY, so
> it reads a bind policy with no N_HIGH_MEMORY node as movable-only.
>
> On systems with CONFIG_CPUSETS=n, nothing rebinds policies when memory
> is removed, so offlining all memory on the nodes a bind policy names
> leaves it with none. The policy is then treated as movable-only, and
> movable allocations are restricted to nodes without memory.
>
> This results in allocations failures, a VM_FAULT_OOM leak, and then
> an infinitely retrying fault that hangs the process.
>
>   page allocation failure: order:0, mode:0x140dca ... nodemask=2
>   Huh VM_FAULT_OOM leaked out to the #PF handler. Retrying PF
>
> Ignore a bind policy whose nodes have no memory. policy_nodemask()
> already ignores a bind policy that does not intersect the cpuset.
> This covers hugetlb's policy_mbind_nodemask() as well.
>
> If the nodes regain memory, the policy applies again.
>
> CPUSETS=n with HOTREMOVE=y is unlikely a common configuration, so this
> isn't marked for stable.

Also no Fixes?

>
> Signed-off-by: Gregory Price (Meta) <gourry@gourry.net>
> ---
>  mm/mempolicy.c | 4 ++++
>  1 file changed, 4 insertions(+)
>

LGTM.

Reviewed-by: Zi Yan <ziy@nvidia.com>


Best Regards,
Yan, Zi

Re: [PATCH] mm/mempolicy: ignore a bind policy whose nodes have no memory

[Gregory Price (Meta)]

On 2026-11-13 14:47 -0500, Zi Yan wrote:
> On 13 Nov 2026, at 14:26, Gregory Price (Meta) wrote:
> 
> > apply_policy_zone() assumes that policy->nodes intersects N_MEMORY, so
> > it reads a bind policy with no N_HIGH_MEMORY node as movable-only.
> >
> > On systems with CONFIG_CPUSETS=n, nothing rebinds policies when memory
> > is removed, so offlining all memory on the nodes a bind policy names
> > leaves it with none. The policy is then treated as movable-only, and
> > movable allocations are restricted to nodes without memory.
> >
> > This results in allocations failures, a VM_FAULT_OOM leak, and then
> > an infinitely retrying fault that hangs the process.
> >
> >   page allocation failure: order:0, mode:0x140dca ... nodemask=2
> >   Huh VM_FAULT_OOM leaked out to the #PF handler. Retrying PF
> >
> > Ignore a bind policy whose nodes have no memory. policy_nodemask()
> > already ignores a bind policy that does not intersect the cpuset.
> > This covers hugetlb's policy_mbind_nodemask() as well.
> >
> > If the nodes regain memory, the policy applies again.
> >
> > CPUSETS=n with HOTREMOVE=y is unlikely a common configuration, so this
> > isn't marked for stable.
> 
> Also no Fixes?
>

It wasn't quite obvious what to tag exactly.  Since I don't think it's
worth backporting, wasn't sure I should bother spending time on the
Fixes tag.

-- 
~Gregory

Re: [PATCH] mm/mempolicy: ignore a bind policy whose nodes have no memory

[Zi Yan]

On 13 Nov 2026, at 15:14, Gregory Price (Meta) wrote:

> On 2026-11-13 14:47 -0500, Zi Yan wrote:
>> On 13 Nov 2026, at 14:26, Gregory Price (Meta) wrote:
>>
>>> apply_policy_zone() assumes that policy->nodes intersects N_MEMORY, so
>>> it reads a bind policy with no N_HIGH_MEMORY node as movable-only.
>>>
>>> On systems with CONFIG_CPUSETS=n, nothing rebinds policies when memory
>>> is removed, so offlining all memory on the nodes a bind policy names
>>> leaves it with none. The policy is then treated as movable-only, and
>>> movable allocations are restricted to nodes without memory.
>>>
>>> This results in allocations failures, a VM_FAULT_OOM leak, and then
>>> an infinitely retrying fault that hangs the process.
>>>
>>>   page allocation failure: order:0, mode:0x140dca ... nodemask=2
>>>   Huh VM_FAULT_OOM leaked out to the #PF handler. Retrying PF
>>>
>>> Ignore a bind policy whose nodes have no memory. policy_nodemask()
>>> already ignores a bind policy that does not intersect the cpuset.
>>> This covers hugetlb's policy_mbind_nodemask() as well.
>>>
>>> If the nodes regain memory, the policy applies again.
>>>
>>> CPUSETS=n with HOTREMOVE=y is unlikely a common configuration, so this
>>> isn't marked for stable.
>>
>> Also no Fixes?
>>
>
> It wasn't quite obvious what to tag exactly.  Since I don't think it's
> worth backporting, wasn't sure I should bother spending time on the
> Fixes tag.

I can imagine that. We probably can blame mbind or hotremove, but the
commit might be too old to be meaningful. It is all good now.

Best Regards,
Yan, Zi