On 24.11.21 14:48, Jason Gunthorpe wrote:

On Wed, Nov 24, 2021 at 02:29:38PM +0100, David Hildenbrand wrote:

quoted

On 24.11.21 14:28, Jason Gunthorpe wrote:

quoted

On Wed, Nov 24, 2021 at 02:25:09PM +0100, David Hildenbrand wrote:

quoted

On 24.11.21 14:23, Jason Gunthorpe wrote:

quoted

On Wed, Nov 24, 2021 at 09:57:32AM +0100, David Hildenbrand wrote:

quoted

Unfortunately it will only be a band aid AFAIU. I can rewrite my
reproducer fairly easily to pin the whole 2M range first, pin a second
time only a single page, and then unpin the 2M range, resulting in the
very same way to block THP. (I can block some THP less because I always
need the possibility to memlock 2M first, though).

Oh!

The issue is GUP always pins an entire compound, no matter how little
the user requests.

That's a different issue. I make sure to split the compound page before
pinning anything :)

?? Where is that done in GUP?

It's done in my reproducer manually.

Aren't there many ways for hostile unpriv userspace to cause memory
fragmentation? You are picking on pinning here, but any approach that
forces the kernel to make a kalloc on a THP subpage would do just as
well.

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.

Arguably if we want to point to an issue here it is in MADV_FREE/etc
that is the direct culprit in allowing userspace to break up THPs and
then trigger fragmentation.

If the objective is to prevent DOS of THP then MADV_FREE should
conserve the THP and migrate the subpages to non-THP
memory.

FOLL_LONGTERM is not the issue here.

Thanks Jason for the discussion but this is where I'll opt out for now
because we seem to strongly disagree and as I said:

"I'm going to leave judgment how bad this is or isn't to the educated
reader, and I'll stop spending time on this as I have more important
things to work on."

But I'm going to leave one last comment to eventually give you a
different perspective: after MADV_DONTNEED the compound page sits on the
deferred split queue and will get split either way soon. People are
right now discussion upstream to even split synchronously, which would
move MADV_FREE out of the picture completely.

My position that FOLL_LONGTERM for unprivileged users is a strong no-go
stands as it is. Not MADV_FREE speeding up the compound page split in my
reproducer. Not MADV_DONTNEED allowing us to zap parts of a THP (I could
even have just used munmap or even mmap(MAP_FIXED)).

-- 
Thanks,

David / dhildenb