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

[Gregory Price <gourry@gourry.net>]

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.

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?

Just spitballing here on the GFP issue since that seems to be coming to
a head on multiple fronts.

~Gregory