Re: [PATCH v5 mm-new 0/6] mm: hugetlb: allocate frozen gigantic folio

[Kefeng Wang <wangkefeng.wang@huawei.com>]

On 2026/1/8 11:25, Zi Yan wrote:
> On 7 Jan 2026, at 20:53, Kefeng Wang wrote:
> 
>> On 2026/1/8 9:05, Kefeng Wang wrote:
>>>
>>>
>>> On 2026/1/8 3:38, Zi Yan wrote:
>>>> On 7 Jan 2026, at 13:39, Mark Brown wrote:
>>>>
>>>>> On Wed, Jan 07, 2026 at 07:31:30PM +0200, Claudiu Beznea wrote:
>>>>>> On 12/30/25 09:24, Kefeng Wang wrote:
>>>>>
>>>>>>> Introduce alloc_contig_frozen_pages() and cma_alloc_frozen_compound()
>>>>>>> which avoid atomic operation about page refcount, and then convert to
>>>>>>> allocate frozen gigantic folio by the new helpers in hugetlb to cleanup
>>>>>>> the alloc_gigantic_folio().
>>>>>>
>>>>>> I'm seeing the following issues on the Renesas RZ/G3S SoC when doing suspend
>>>>>> to idle:
>>>>>>
>>>>>> [  129.636729] Unable to handle kernel paging request at virtual address
>>>>>> dead000000000108
>>>>>> [  129.644674] Mem abort info:
>>>>>> [  129.647456]   ESR = 0x0000000096000044
>>>>>
>>>>> This is also introducing OOMs when doing at least audio tests (I don't
>>>>> think these are super relevant) on Raspberry Pi 3B+ running NFS root
>>>>> (probably more relevant):
>>>>>
>>>>> [   64.064256] Unable to handle kernel paging request at virtual address fffffdffc1000000
>>>>>
>>>>> ...
>>>>>
>>>>> [   64.087583] Call trace:
>>>>> [   64.087586]  kmem_cache_free+0x88/0x434 (P)
>>>>> [   64.087598]  skb_free_head+0x9c/0xb8
>>>>> [   64.087608]  skb_release_data+0x120/0x174
>>>>> [   64.087615]  __kfree_skb+0x2c/0x44
>>>>> [   64.087622]  tcp_data_queue+0x948/0xe50
>>>>>
>>>>> Full log:
>>>>>
>>>>>     https://lava.sirena.org.uk/scheduler/job/2341856#L1721
>>>>>
>>>>> Bisection identifies:
>>>>>
>>>>> [fb9a328d30400dbc8b2ea5a57daeb28bedac398b] mm: cma: add cma_alloc_frozen{_compound}()
>>>>>
>>>>> as being the comit that introduces the issue.  Bisect log with links to
>>>>> further test runs:
>>>>
>>>> Hi Mark and Claudiu,
>>>
>>> Thanks for the reports.
>>>
>>>>
>>>> Can you try the patch below to see if it fixes the issue? Basically,
>>>> in cma_release(), count was used to drop page ref and decreased to 0,
>>>> but after the loop, count becomes -1 and __cma_release_frozen()
>>>> is releasing unnecessary pages.
>>>
>>> Oh，sorry for introducing the regression, my previous self-tests were
>>> more focused on the hugetlb part, I should be more careful about this,
>>> and thanks Zi Yan for the quick fix, I will do more check and test for
>>> the non-hugetlb part.
>>>
>>>
>>
>> Based on the cma_debug interface, I performed quick tests to reproduce
>> the issue before Zi's fix. With the fix applied, the crash was resolved,
>> and no other issues were observed during testing.
> 
> It seems that the series is dropped from Andrew’s tree. You probably want
> to send a new version with the fix folded.
> 

OK, thanks for the remind, will do.

> Best Regards,
> Yan, Zi
>