linux-kernel - Re: [PATCH 0/3] mm: treewide: make get_free

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3301af1f-c24a-4e43-ad59-402e244d5552@suse.cz>
Date: Mon, 20 Oct 2025 10:54:27 +0200
From: Vlastimil Babka <vbabka@...e.cz>
To: Mike Rapoport <rppt@...nel.org>, Matthew Wilcox <willy@...radead.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
 Brendan Jackman <jackmanb@...gle.com>, David Hildenbrand <david@...hat.com>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Jiri Slaby <jirislaby@...nel.org>, Johannes Weiner <hannes@...xchg.org>,
 Julia Lawall <Julia.Lawall@...ia.fr>,
 "Liam R. Howlett" <Liam.Howlett@...cle.com>,
 Lorenzo Stoakes <lorenzo.stoakes@...cle.com>, Michal Hocko
 <mhocko@...e.com>, Suren Baghdasaryan <surenb@...gle.com>,
 Zi Yan <ziy@...dia.com>, linux-kernel@...r.kernel.org, linux-mm@...ck.org,
 Al Viro <viro@...IV.linux.org.uk>
Subject: Re: [PATCH 0/3] mm: treewide: make get_free_pages() and return void *

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/ 
> If it was a long time ago, he might not object it now.

Did the circumstances change in a positive way? Using a semantic patch might
make it less painfull to apply in a flag day manner, although depends on how
much is that "a bit of manual tweaking" you mention.

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