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

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

On 11/14/26 21:25, Gregory Price (Meta) wrote:
> On 2026-11-14 21:16 +0100, David Hildenbrand (Arm) wrote:
>> On 11/14/26 18:41, Gregory Price (Meta) wrote:
>>>
>>> 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.
> 
> Just want to make sure the bases are covered.
> 

Yes, and I'd be very happy to learn about use cases.

Maybe we can let this stay in -next for a while before moving forward with this?

> If others are ok with this change, it doesn't look unreasonable to me.
> 
> Although I'd wonder whether just using max_map_count's limit instead of
> adding a new toggle would just be cleaner and avoid adding a new uapi.

I considered it but discarded that. Having 1mil on Fedora et al is not
particularly helpful. Both are related but, in practice, completely separate
concepts.

-- 
Cheers,

David