linux-kernel - Re: [PATCH] replace free hugepage folios after migration

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] [day] [month] [year] [list]

Message-ID: <85bfb9b7-09fc-45e3-888d-71c848aaf00d@126.com>
Date: Thu, 9 Jan 2025 17:50:40 +0800
From: Ge Yang <yangge1116@....com>
To: David Hildenbrand <david@...hat.com>, akpm@...ux-foundation.org
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org, stable@...r.kernel.org,
 21cnbao@...il.com, baolin.wang@...ux.alibaba.com, muchun.song@...ux.dev,
 liuzixing@...on.cn
Subject: Re: [PATCH] replace free hugepage folios after migration



在 2025/1/9 5:05, David Hildenbrand 写道:
> Sorry for the late reply, holidays ...
> 
>>> Did you ever try allocating a larger range with a single
>>> alloc_contig_range() call, that possibly has to migrate multiple hugetlb
>>> folios in one go (and maybe just allocates one of the just-freed hugetlb
>>> folios as migration target)?
>>>
>>
>> I have tried using a single alloc_contig_range() call to allocate a
>> larger contiguous range, and it works properly. This is because during
>> the period between __alloc_contig_migrate_range() and
>> isolate_freepages_range(), no one allocates a hugetlb folio from the
>> free hugetlb pool.
> 
> Did you trigger the following as well?
> 
> alloc_contig_range() that covers multiple in-use hugetlb pages, like
> 
> [ huge 0 ] [ huge 1 ] [ huge 2 ] [ huge 3 ]
> 
> I assume the following happens:
> 
> To migrate huge 0, we have to allocate a fresh page from the buddy. 
> After migration, we return now-free huge 0 to the pool.
> 
> To migrate huge 1, we can just grab now-free huge 0 from the pool, and 
> not allocate a fresh one from the buddy.
> 
> At least that's my impression when reading alloc_migration_target()- 
>  >alloc_hugetlb_folio_nodemask().

Thank you very much for your suggestions.

It needs to be discussed in two different scenarios:

1, When All Free HugeTLB Pages in the Pool Are Allocated, 
available_huge_page() Returns false

If available_huge_page() returns false, indicating that no free huge 
pages are available in the hugeTLB pool, we will invoke 
alloc_migrate_hugetlb_folio() to allocate a new folio. A temporary flag 
will be set on this new folio. After the migration of the hugeTLB folio 
is completed, the temporary flag will be transferred from the new folio 
to the old one. Any folio with the temporary flag, when freed, will be 
directly released to the buddy allocator.

2, When Some Free HugeTLB Pages in the Pool Are Still Available, 
available_huge_page() Returns true

If available_huge_page() returns true, indicating that there are still 
free huge pages available in the hugeTLB pool, we will call 
dequeue_hugetlb_folio_node() to allocate a new folio. After the 
migration of the hugeTLB folio is completed, the old folio will be 
released back to the free hugeTLB pool. However, this scenario may pose 
potential issues, as you mentioned earlier. It seems that the issue can 
be resolved by the following approach:

dequeue_hugetlb_folio_node_exact() {
     list_for_each_entry(folio, &h->hugepage_freelists[nid], lru) {
         if (is_migrate_isolate_page(folio)) {  //determine whether a 
hugetlb page is isolated
              continue;
         }
     }
}



> 
> Or is for some reason available_huge_pages()==false and we always end up 
> in alloc_migrate_hugetlb_folio()->alloc_fresh_hugetlb_folio()?
> 
> Sorry for the stupid questions, the code is complicated, and I cannot 
> see how this would work.
>