mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [PATCH 0/2] mm/mempolicy: shared policy limits for tmpfs/shmem/guest_memfd
@ 2026-11-13 21:36 David Hildenbrand (Arm)
  2026-11-13 21:36 ` [PATCH 1/2] mm/mempolicy: merge adjacent shared policy ranges David Hildenbrand (Arm)
  2026-11-13 21:36 ` [PATCH 2/2] mm/mempolicy: limit shared policy ranges per inode David Hildenbrand (Arm)
  0 siblings, 2 replies; 3+ messages in thread
From: David Hildenbrand (Arm) @ 2026-11-13 21:36 UTC (permalink / raw)
  To: Hugh Dickins, Baolin Wang, Gregory Price, Zi Yan, Joshua Hahn,
	Rakie Kim, Ying Huang, Andrew Morton, Lorenzo Stoakes,
	Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
	Suren Baghdasaryan, Michal Hocko, Jonathan Corbet, Shuah Khan,
	Randy Dunlap
  Cc: linux-mm, linux-kernel, linux-doc, David Hildenbrand (Arm)

For some reason we thought it would be a good idea to let users create
as many shared policy ranges for shmem/tmpfs as they want. And
guest_memfd inherited that handling.

Fortunately, at least for guest_memfd we know that we shouldn't really
have more than one shared policy right now in practice.

While we now at least charge these allocations to the memcg, users can
still allocate possibly many, and cause trouble, for example, by having
long list walks under spinlocks.

Instead of trying to improve things, let's just stop the user from doing
stupid things.

Essentially: limit the number of shared policy ranges per inode to 1024
as default. Let the admin increase that limit. 1024 is likely still
plenty: who maps a shmem/tmpfs/guest_memfd file and configures that many
mempolicies on it through separate VMAs?

Maybe we should set the limit even lower ... but 1024 feels at least like a
start where no user case should be impacted.

Patch #2 can be considered a fix, but I am not tagging it like that.
It's been that way forever ... should we? The impact is primarily just
wasting kernel memory and doing a lot of expensive operation under
locks.

Patch #1 prepares for that by merging adjacent policies if they are equal,
to reduce the number of policies further if some user space actually does
something questionable on sub-ranges.

This is not super urgent but something that should be addressed.

Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
---
David Hildenbrand (Arm) (2):
      mm/mempolicy: merge adjacent shared policy ranges
      mm/mempolicy: limit shared policy ranges per inode

 Documentation/admin-guide/sysctl/vm.rst | 18 ++++++++
 include/linux/mempolicy.h               |  1 +
 mm/mempolicy.c                          | 74 +++++++++++++++++++++++++++++++++
 3 files changed, 93 insertions(+)

---

base-commit: c6e0cad6c9b4180bb229db06e5b062c5ce0723bd

change-id: 20261113-mempolicy_limit-6f043870d04b

--

Cheers,

David


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2026-11-13 21:36 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-11-13 21:36 [PATCH 0/2] mm/mempolicy: shared policy limits for tmpfs/shmem/guest_memfd David Hildenbrand (Arm)
2026-11-13 21:36 ` [PATCH 1/2] mm/mempolicy: merge adjacent shared policy ranges David Hildenbrand (Arm)
2026-11-13 21:36 ` [PATCH 2/2] mm/mempolicy: limit shared policy ranges per inode David Hildenbrand (Arm)

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®