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

["Vlastimil Babka (SUSE)" <vbabka@kernel.org>]

On 3/19/26 18:38, Brendan Jackman wrote:
> On Thu, 19 Mar 2026 at 18:03, Vlastimil Babka (SUSE) <vbabka@kernel.org> 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?

Yeah, at least I don't know a better way.

> I did that in [0] but I'm rather sheepish about it, I only went for it

Right.

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

I think it's a hazard in any case where there are multiple arguments to a
function where one is gfp flags and other some integer, and somebody gets
the order wrong.

But I just verified that at least in the kmalloc_objs() mistake, sparse will
flag it, thanks to the __bitwise annotation. Would be better if compiler
did, but it makes the case for changing gfp_t smaller if it was too
disruptive (it likely would be).

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