On 24.11.21 16:34, Jason Gunthorpe wrote: > On Wed, Nov 24, 2021 at 03:14:00PM +0100, David Hildenbrand wrote: > >> I'm not aware of any where you can fragment 50% of all pageblocks in the >> system as an unprivileged user essentially consuming almost no memory >> and essentially staying inside well-defined memlock limits. But sure if >> there are "many" people will be able to come up with at least one >> comparable thing. I'll be happy to learn. > > If the concern is that THP's can be DOS'd then any avenue that renders > the system out of THPs is a DOS attack vector. Including all the > normal workloads that people run and already complain that THPs get > exhausted. > > A hostile userspace can only quicken this process. We can not only fragment THP but also easily smaller compound pages, with less impact though (well, as long as people want more than 0.1% per user ...). We want to make more excessive use of THP; the whole folio work is about using THP. Some people are even working on increasing the MAX_ORDER and introduce gigantic THP. And here we are having mechanisms available to unprivileged users to just sabotage the very thing at its core extremely easily. Personally, I think this is very bad, but that's just my humble opinion. > >> My position that FOLL_LONGTERM for unprivileged users is a strong no-go >> stands as it is. > > As this basically excludes long standing pre-existing things like > RDMA, XDP, io_uring, and more I don't think this can be the general > answer for mm, sorry. Let's think about options to restrict FOLL_LONGTERM usage: One option would be to add toggle(s) (e.g., kernel cmdline options) to make relevant mechanisms (or even FOLL_LONGTERM itself) privileged. The admin can opt in if unprivileged users should have that capability. A distro might overwrite the default and set it to "on". I'm not completely happy about that. Another option would be not accounting FOLL_LONGTERM as RLIMIT_MEMLOCK, but instead as something that explicitly matches the differing semantics. We could have a limit for privileged and one for unprivileged users. The default in the kernel could be 0 but an admin/system can overwrite it to opt in and a distro might apply different rules. Yes, we're back to the original question about limits, but now with the thought that FOLL_LONGTERM really is different than mlock and potentially more dangerous. At the same time, eventually work on proper alternatives with mmu notifiers (and possibly without the any such limits) where possible and required. (I assume it's hardly possible for RDMA because of the way the hardware works) Just some ideas, open for alternatives. I know that for the cases where we want it to "just work" for unprivileged users but cannot even have alternative implementations, this is bad. > > Sure, lets stop now since I don't think we can agree. Don't get me wrong, I really should be working on other stuff, so I have limited brain capacity and time :) OTOH I'm willing to help at least discuss alternatives. Let's think about realistic alternatives to keep FOLL_LONGTERM for any user working (that would tackle the extreme fragmentation issue at least, ignoring e.g., other fragmentation we can trigger with FOLL_LONGTERM or ZONE_MOVABLE/MIGRATE_CMA): The nasty thing really is splitting a compound page and then pinning some pages, even if it's pinning the complete compound range. Ideally, we'd defer any action to the time we actually FOLL_LONGTERM pin a page. a) I think we cannot migrate pages when splitting the PMD (e.g., unmap, MADV_DONTNEED, swap?, page compaction?). User space can just pin the compound page to block migration. b) We might migrate pages when splitting the compound page. In split_huge_page_to_list() we know that we have nobody pinning the page. I did not check if it's possible. There might be cases where it's not immediately clear if it's possible (e.g., inside shrink_page_list()) It would mean that we would migrate pages essentially any time we split a compound page because there could be someone FOLL_LONGTERM pinning the page later. Usually we'd expect page compaction to fix this up on actual demand. I'd call this sub-optimal. c) We migrate any time someone FOLL_LONGTERM pins a page and the page is not pinned yet -- because it might have been a split compound page. I think we can agree that that's not an option :) d) We remember if a page was part of a compound page and was not freed yet. If we FOLL_LONGTERM such a page, we migrate it. Unfortunately, we're short on pageflags for anon pages I think. Hm, alternatives? -- Thanks, David / dhildenb
