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 for Android: free password hash cracker in your pocket

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

Message-ID: <dfb9fd83-3fe1-4596-bc94-c3f9c3c916ce@redhat.com>
Date: Mon, 20 Oct 2025 13:21:19 +0200
From: David Hildenbrand <david@...hat.com>
To: Vlastimil Babka <vbabka@...e.cz>, Jiri Slaby <jirislaby@...nel.org>,
 Matthew Wilcox <willy@...radead.org>, Mike Rapoport <rppt@...nel.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
 Brendan Jackman <jackmanb@...gle.com>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.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
Subject: Re: [PATCH 0/3] mm: treewide: make get_free_pages() and return void *

On 20.10.25 12:31, Vlastimil Babka wrote:
> On 10/20/25 11:13, David Hildenbrand wrote:
>> On 20.10.25 11:08, Jiri Slaby wrote:
>>> On 20. 10. 25, 11:02, David Hildenbrand wrote:
>>>> Regarding the metadata overhead, in 2015 Linus wrote in that thread:
>>>>
>>>> "Long ago, allocating a page using kmalloc() was a bad idea, because
>>>> there was overhead for it in the allocation and the code.
>>>>
>>>> These days, kmalloc() not only doesn't have the allocation overhead,
>>>> but may actually scale better too, thanks to percpu caches etc."
>>>>
>>>> What's that status of that 10 years later?
>>>
>>> AFAI skimmed through the code, for allocations > 2 pages
>>> (KMALLOC_MAX_CACHE_SIZE) -- if size is a constant -- slub resorts to
>>> alloc_pages().
>>>
>>> For smaller ones (1 and 2 pages), there is a very little overhead in
>>> struct slab -- mm people, please correct me if I am wrong.
>>
>> If it's really only "struct slab", then there is currently no overhead.
>> Once it is decoupled from "struct page", there would be some.
> 
> Yes, but there's potentially better scalability and more debugging
> possibilities as benefits.

Agreed.

> 
>> IIUC, I'm surprised that larger allocations wouldn't currently end up in
>> PageSlab() pages.
> Can you elaborate why surprised?

Primarily because I think it's a bit inconsistent. I would have assumed 
that whatever came out of kmalloc() could be identified as such.

One of the benefits of PageSlab() is that we can better sanity check 
that these pages will not get mapped into user space by accident: see 
page_has_type() check in validate_page_before_insert().

But given that ___kmalloc_large_node() today also allocates frozen 
pages, validate_page_before_insert() would similarly bail out if it 
stumbles over the !folio_ref_count(folio).

-- 
Cheers

David / dhildenb