linux-kernel - Re: [PATCH V4] mm/hugetlb: wait for hugetlb folios to be freed

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: <1C15A7E5-D78A-40DA-B7C5-3F49E790AC58@linux.dev>
Date: Wed, 19 Feb 2025 11:49:57 +0800
From: Muchun Song <muchun.song@...ux.dev>
To: yangge1116@....com
Cc: akpm@...ux-foundation.org,
 linux-mm@...ck.org,
 linux-kernel@...r.kernel.org,
 stable@...r.kernel.org,
 21cnbao@...il.com,
 david@...hat.com,
 baolin.wang@...ux.alibaba.com,
 osalvador@...e.de,
 liuzixing@...on.cn
Subject: Re: [PATCH V4] mm/hugetlb: wait for hugetlb folios to be freed



> On Feb 19, 2025, at 11:46, yangge1116@....com wrote:
> 
> From: Ge Yang <yangge1116@....com>
> 
> Since the introduction of commit c77c0a8ac4c52 ("mm/hugetlb: defer freeing
> of huge pages if in non-task context"), which supports deferring the
> freeing of hugetlb pages, the allocation of contiguous memory through
> cma_alloc() may fail probabilistically.
> 
> In the CMA allocation process, if it is found that the CMA area is occupied
> by in-use hugetlb folios, these in-use hugetlb folios need to be migrated
> to another location. When there are no available hugetlb folios in the
> free hugetlb pool during the migration of in-use hugetlb folios, new folios
> are allocated from the buddy system. A temporary state is set on the newly
> allocated folio. Upon completion of the hugetlb folio migration, the
> temporary state is transferred from the new folios to the old folios.
> Normally, when the old folios with the temporary state are freed, it is
> directly released back to the buddy system. However, due to the deferred
> freeing of hugetlb pages, the PageBuddy() check fails, ultimately leading
> to the failure of cma_alloc().
> 
> Here is a simplified call trace illustrating the process:
> cma_alloc()
>    ->__alloc_contig_migrate_range() // Migrate in-use hugetlb folios
>        ->unmap_and_move_huge_page()
>            ->folio_putback_hugetlb() // Free old folios
>    ->test_pages_isolated()
>        ->__test_page_isolated_in_pageblock()
>             ->PageBuddy(page) // Check if the page is in buddy
> 
> To resolve this issue, we have implemented a function named
> wait_for_freed_hugetlb_folios(). This function ensures that the hugetlb
> folios are properly released back to the buddy system after their migration
> is completed. By invoking wait_for_freed_hugetlb_folios() before calling
> PageBuddy(), we ensure that PageBuddy() will succeed.
> 
> Fixes: c77c0a8ac4c52 ("mm/hugetlb: defer freeing of huge pages if in non-task context")
> Signed-off-by: Ge Yang <yangge1116@....com>
> Cc: <stable@...r.kernel.org>

Reviewed-by: Muchun Song <muchun.song@...ux.dev>

Thanks.