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

[Gregory Price]

On Fri, May 15, 2026 at 09:31:15AM +0000, Brendan Jackman wrote:
> On Wed May 13, 2026 at 5:59 PM UTC, Gregory Price wrote:
> >
> > 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?
> 

The important thing is that the API growth, if there is one, needs to be
extensible and not specific to a particular user case.

alloc_pages_unmapped() is just replacing a GFP flag with a function
call.  Now we've encourage alloc_pages_foobarbazbazinga() to be
implemented.

So we should give some careful thought to whether growing the allocator
interface is a good idea at all - and if so very intentionally.

I made a similar comment on MST's virtio series [0] about trying not to
increase the buddy surface - because it makes it harder to test and
easier for people to do the wrong thing.

So if we are going to increase the surface, maybe the intent should be
to have an eventual migration, rather than a permanent surface increase.

[0] https://lore.kernel.org/linux-mm/aeozRZ9AvW2jTQkX@gourry-fedora-PF4VCD3F/

> 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?
> 

This is actually what i meant about some GFP flags may more accurately
be described as alloc flags.  They say something about where to allocate
from rather than something about the page itself (ZONE_DMA vs ZONE_CMA
vs ZONE_MOVABLE, etc).

> > 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"
> 

That sounds more like an allocation context which implies a set of GFP
flags, rather a specific directive to give the allocator.

> - __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" 
> 

I don't think this necessarily implies user data, it just implies
wanting an unmapped page.  The caller's intent isn't necessarily encoded
by this flag (although we can derive it from existing use cases, who
knows what crazy stuff people will come up with).

> 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.
> 

I don't know that we can call any particular idea "conceptionally
correct" when GFP flags themselves are a mishmash of ideas already :]
which is actually the core of the issue isn't it? n_n;;;


~Gregory