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

["David Hildenbrand (Arm)" <david@kernel.org>]

On 11/14/26 18:41, Gregory Price (Meta) wrote:
> 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.

Which is fine if there is no valid userspace that does something stupid.

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

Sure, that's expected. The admin can raise the default for these odd cases.

I did some digging and was not able to come up with any valid use case.

The only is that you have many VMAs for the same file mapping (mprotect etc) and
then do a mind().

But that's precisely what patch #1 does.

> 
> 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.

Do you know a single valid use case that's not solved by patch #1 and would
trigger that many policies?

Ai was not able to come up with anything for me.

-- 
Cheers,

David