Re: [PATCH 0/3] mm: treewide: make get_free_pages() and return void *

[David Hildenbrand <david@redhat.com>]

On 20.10.25 10:54, Vlastimil Babka wrote:
> On 10/19/25 16:25, Mike Rapoport wrote:
>> On Sun, Oct 19, 2025 at 01:30:47AM +0100, Matthew Wilcox wrote:
>>> On Sat, Oct 18, 2025 at 12:29:59PM +0300, Mike Rapoport wrote:
>>>> Vast majority of allocations that use get_free_pages() and its derivatives
>>>> cast the returned unsigned long to a pointer and then cast it back to
>>>> unsigned long when freeing the memory.
>>>>
>>>> These castings are useless and only obfuscate the code.
>>>>
>>>> Make get_free_pages() and friends return 'void *' and free_pages() accept
>>>> 'void *' as its address parameter.
>>>
>>> No.  Linus has rejected this change before.  I can't find it now, it was
>>> a long time ago.
> 
> Here's a lore link
> https://lore.kernel.org/all/CA+55aFwp4iy4rtX2gE2WjBGFL=NxMVnoFeHqYa2j1dYOMMGqxg@mail.gmail.com/

You beat me to it :)

[...]

>>> Most of them shouldn't be using get_free_pages() at all, they should be
>>> using kmalloc().
> 
> Changing to kmalloc() would have to be careful, what if the callers rely on
> doing e.g. get_page() later. It would however be useful to dintinguish "I
> want a page-sized buffer" (note that it's guaranteed to be aligned by
> kmalloc() these days, which it wasn't in 2015) from "I really want a page".
> But many of the latter cases maybe want a struct page then and are using
> alloc_pages()?

I agree. I guess whoever wants a "struct page" (e.g., to use a different 
memdesc later) should be asking for a page in the first place, not 
something that will be slab-typed right from the start.

>> Don't know if most but some of them could. Still, we'd have a bunch of
>> get_free_pages() users with needless castings.
>> And converting callers that should use kmalloc() is a long and tedious
>> process, while here we get an API improvement in a single automated change.
> Maybe a more feasible way would be to rename to something more coherent,
> while keeping the old interfaces alive for a while for easier backporting.
> because __get_free_pages() / free_pages() is not really great naming.
> If possible it would be nice to also make __GFP_COMP implicit in the new API.

Agreed to all. But we will have to be a bit careful with __GFP_COMP.

-- 
Cheers

David / dhildenb