Re: [PATCH] hugetlb: Convert alloc_buddy_hugetlb_folio to use a folio

[Muchun Song <muchun.song@linux.dev>]

> On Apr 3, 2024, at 12:55, Oscar Salvador <osalvador@suse.de> wrote:
> 
> On Tue, Apr 02, 2024 at 09:06:54PM +0100, Matthew Wilcox (Oracle) wrote:
>> While this function returned a folio, it was still using __alloc_pages()
>> and __free_pages().  Use __folio_alloc() and put_folio() instead.  This
>> actually removes a call to compound_head(), but more importantly, it
>> prepares us for the move to memdescs.
>> 
>> Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
> 
> Reviewed-by: Oscar Salvador <osalvador@suse.de>
> 
>> - page = __alloc_pages(gfp_mask, order, nid, nmask);
>> + folio = __folio_alloc(gfp_mask, order, nid, nmask);
>> 
>> - /* Freeze head page */
>> - if (page && !page_ref_freeze(page, 1)) {
>> - __free_pages(page, order);
>> + if (folio && !folio_ref_freeze(folio, 1)) {
>> + folio_put(folio);
> 
> This made me look again at the problem we had in the past with
> speculative refcount vs hugetlb pages, and made me think whether there
> are any more users trying to defeat speculative refcounts this way.
> It was discussed some time ago that maybe all pages returned from the buddy
> allocator should have its refcount frozen, to avoid this.

I think you mean this patch [1], right? With alloc_frozen_pages()
introduced, we could get rid of the trick from HugeTLB code.

[1] https://lore.kernel.org/linux-mm/B4889CC0-5D36-44E2-B901-CDC5226995A2@oracle.com/T/#m20457752e757cdafc99c7f5e6a3d8cbbb65fcd3e

> 
> 
> -- 
> Oscar Salvador
> SUSE Labs