Re: [PATCH v2 00/22] mm: Add __GFP_UNMAPPED

[Brendan Jackman]

On Wed May 13, 2026 at 5:59 PM UTC, Gregory Price wrote:
> On Wed, May 13, 2026 at 07:38:01PM +0200, Vlastimil Babka (SUSE) wrote:
>> On 5/13/26 19:28, Gregory Price wrote:
>> > 
>> > Hm.  I'm not quite wrapping my head around the TLB issue fully.
>> > 
>> > If there's no kernel direct mapping, and there's no userland mapping,
>> > the stale TLB entry comes from... the page formerly being present in the
>> > page tables and a stale TLB entry lying about after the page is freed?
>> 
>> It's the direct mapping, we assume it's always there and unchanged, and only
>> kernel can access the contents through it. So nobody flushes it when freeing
>> any pages. Userspace processes can't exploit anything stale there, in
>> absence of kernel's UAF bugs (or e.g. Meltdown like cpu bugs).
>> 
>
> Ah, I follow.
>
> If everything is default-unmapped, then you don't have to worry about
> this issue - except when a stolen block is returned or an ephemeral
> mapping is unmapped after the operation.
>
> pivoting...
>
> On the GFP front, i wonder if you could factor out the core of
> alloc_frozen_pages_noprof() and add alloc_unmapped_pages_noprof()
> which adds (alloc_flags |= ALLOC_UNMAPPED) instead of adding
> __GFP_UNMAPPED.
>
> I have been considering something similar for __GFP_PRIVATE, but this
> has the added downside of increasing the surface of the buddy for each
> new narrow use case (in my case, private nodes, in this case unmapped
> allocations).
>
> unless of course we nip that in the bud with something like
>
> struct page *
> alloc_pages_special(enum buddy_context ctxt, gfp_t gfp_mask, ...)
> {
>     switch (ctxt) {
>        ... internal-only details about how that case is handled ...
>     }
> }
>
> and just go ahead and allow the buddy to grow internally without adding
> new gfp flags or an infinite number of interfaces.

Yeah, this is what I'm thinking too. I don't think growing the interface
is such a big deal if we can put it in mm/internal.h. For __GFP_UNMAPPED
and ASI's equivalent, we would eventually want to expose the functionality
outside of mm/, but that doesn't mean we have to directly expose the
page allocator interface itself. Do you think it's a similar story for
__GFP_PRIVATE?

Anyway my initial thought was a variant of alloc_pages that lets you
directly specify alloc flags alongside/instead of GFP flags. This is
actually a bit fiddly though since the GFP flags -> alloc flags thing
isn't a clean division. Maybe it should be?

> Of course that means users have to know the context in which they're
> being allocated.  Right now you can kind of "transiently cheat" by
> passing a GFP flag through a bunch of interfaces and that makes certain
> allocations reachable - but maybe we should not be encouraging that kind
> of design for these kinds of allocator extensions?

Hm, for __GFP_UNMAPPED (and __GFP_SENSITIVE in the future), it is
nothing to do with the allocation context. It's really expressing
something about the page, i.e:

- __GFP_SENSITIVE means "We might put user data in this page"

- __GFP_UNMAPPED means "We might put user data in this page, and I know
  the kernel doesn't need to access it in the direct map" 

So, for those cases, I think a GFP flag is actually conceptually
correct, the only reason I can see to avoid it is because of bitmap
space.