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

[Brendan Jackman]

On Thu Mar 19, 2026 at 7:58 PM UTC, Vlastimil Babka (SUSE) wrote:
> On 3/19/26 18:38, Brendan Jackman wrote:
>> 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?
>
> 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.

I think this is a C problem rather than a gfp_t problem though. Better
to try and tackle it with treewide efforts like Sparse and Rust IMO.

(Maybe gfp_t is the most common type of arg flags in the kernel? Could
be an argument to be made there I guess).

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

Yeah I think it would be very disruptive indeed.

A thought I'll forward to Roman - we should try having Sashiko[1] run
Sparse and read the output, if it doesn't already. 

[1] https://lwn.net/Articles/1063292/