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

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

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.

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.

-- 
~Gregory