Re: [PATCH 2/2] mm/mempolicy: limit shared policy ranges per inode

["Gregory Price (Meta)" <gourry@gourry.net>]

On 2026-11-13 22:36 +0100, David Hildenbrand (Arm) wrote:
> Shared NUMA policy ranges can accumulate on an inode after its mappings
> are removed. Currently, these nodes are effectively unbounded (even though
> the allcoations are charged).
> 
> An unbounded tree can cause long rwlock hold times when replacing or
> freeing policies. Instead of trying to fix that, it sounds more like
> having many nodes is actually only a scenario for processes trying to
> cause trouble. Most use cases will probably only use a handful of them,
> not millions.
> 
> Add vm.max_shared_policy_count (inspired by vm.max_map_count), defaulting
> to 1024 ranges per inode. Reject updates with -ENOMEM if they would
> increase the count beyond the limit, taking merging, splitting etc.
> into account.
> 
> Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>


This arguably breaks userspace.

A single mapper that tries to set >1024 ranges would start getting
-ENOMEMs unexpectedly with this change.

Multi-task mappers were previously unlimited, but that seems like more
of a nasty unintended corner case - not a real feature.

A single process is already limited on the number of vmas/policies based
on `max_map_count`, so it seems natural to just use max_map_count
directly, but I took a brief look at some distros and most seem to
ship a raised `max_map_count` (>1 million) by default).

I tested that and even 1 million can cause a soft lockup.

Not sure there's an easy solution here, we might have to rework the shm
policy locks.

-- 
~Gregory