Re: [PATCH 0/5] mm: Switch gfp_t to unsigned long

[Brendan Jackman]

On Thu, 19 Mar 2026 at 18:03, Vlastimil Babka (SUSE) <vbabka@xxxxxxxxxx> wrote:
>
> On 3/19/26 17:03, Brendan Jackman wrote:
> > As pointed out by Vlastimil in [0], my proposal for __GFP_UNMAPPED is
> > probably not needed for 32-bit. This offers a way out of the GFP flag
> > scarcity so in preparation for this, flip gfp_t to be 64-bit on 64-bit
> > machines, while leaving it 32-bit on 32-bit machines.
>
> Thanks for tackling this! But now I'm wondering, if we decide to change it,
> would it be worth trying to add some type safety too? To help with cases
> like the recent kmalloc_objs() footgun discussed in this comment thread
> https://lwn.net/Articles/1063356/

Do you mean something similar to pgprot_t?

I did that in [0] but I'm rather sheepish about it, I only went for it
because I think it's especially needed for the specific "type" due to
the migration path creating a high type-unsafety risk. And that was
totally local to a few files in mm/.

Are there common issues with gfp_t in particular besides the
kmalloc_objs() thing? If so then maybe it could make sense. It's not a
problem I've ever run into myself though.

[0] https://lore.kernel.org/all/20260225-page_alloc-unmapped-v1-8-e8808a03cd66@xxxxxxxxxx/