linux-kernel - Re: [PATCH] mm,hugetlb: Allocate frozen pages in alloc_buddy_hugetlb

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: <Z_kldseGr033Hqny@casper.infradead.org>
Date: Fri, 11 Apr 2025 15:21:42 +0100
From: Matthew Wilcox <willy@...radead.org>
To: David Hildenbrand <david@...hat.com>
Cc: Oscar Salvador <osalvador@...e.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Muchun Song <muchun.song@...ux.dev>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, Vlastimil Babka <vbabka@...e.cz>
Subject: Re: [PATCH] mm,hugetlb: Allocate frozen pages in
 alloc_buddy_hugetlb_folio

On Fri, Apr 11, 2025 at 03:44:31PM +0200, David Hildenbrand wrote:
> I assume htlb_alloc_mask() will always include _GFP_COMP.

static inline gfp_t htlb_alloc_mask(struct hstate *h)
{
        gfp_t gfp = __GFP_COMP | __GFP_NOWARN;

> But semantically, it might be wrong: __folio_alloc() will in the memdesc
> world also make sure to allocate the memdesc, __alloc_frozen_pages() not.
> 
> Maybe one would want a __alloc_frozen_folio() .... @willy?

This is fine.  Yes, it'll need to be modified when we get to the
separately allocated memdesc, but there's a number of places that
cast the freshly allocated page to a folio, and I'll have to come up
with a way to catch them all.

Reviewed-by: Matthew Wilcox (Oracle) <willy@...radead.org>

Oscar, if you want to take on the gigantic allocation next ...

 - I don't think we need folio_alloc_gigantic() to be wrapped in
   alloc_hooks
 - folio_alloc_gigantic() should return a frozen folio
 - as should hugetlb_cma_alloc_folio()