linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Konrad Dybcio <konradybcio@gmail.com>
To: Zi Yan <ziy@nvidia.com>, Mark Brown <broonie@kernel.org>,
	Claudiu Beznea <claudiu.beznea@tuxon.dev>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	David Hildenbrand <david@redhat.com>,
	Oscar Salvador <osalvador@suse.de>,
	Muchun Song <muchun.song@linux.dev>,
	linux-mm@kvack.org, sidhartha.kumar@oracle.com,
	jane.chu@oracle.com, Vlastimil Babka <vbabka@suse.cz>,
	Brendan Jackman <jackmanb@google.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Matthew Wilcox <willy@infradead.org>
Subject: Re: [PATCH v5 mm-new 0/6] mm: hugetlb: allocate frozen gigantic folio
Date: Thu, 8 Jan 2026 10:14:28 +0100	[thread overview]
Message-ID: <acf3ae82-2cf3-4c85-bbb9-bbcbe2b7be3c@gmail.com> (raw)
In-Reply-To: <7253A444-97D1-4256-9AD9-BCFF66437510@nvidia.com>

On 1/7/26 8:38 PM, 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,
> 
> 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.
> 
> Thanks.
> 
> 
> From ece23da65ea7210e1fcb51ee9c27aec19b84811c Mon Sep 17 00:00:00 2001
> From: Zi Yan <ziy@nvidia.com>
> Date: Wed, 7 Jan 2026 14:23:15 -0500
> Subject: [PATCH] mm/cma: fix cma_release by not decreasing count to 0.
> Content-Type: text/plain; charset="utf-8"
> 
> Signed-off-by: Zi Yan <ziy@nvidia.com>
> ---

This also fixes booting on a number of Qualcomm platforms

Tested-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Konrad


      parent reply	other threads:[~2026-01-08  9:14 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-30  7:24 Kefeng Wang
2025-12-30  7:24 ` [PATCH v5 1/6] mm: debug_vm_pgtable: add debug_vm_pgtable_free_huge_page() Kefeng Wang
2026-01-02 18:51   ` Sid Kumar
2025-12-30  7:24 ` [PATCH v5 2/6] mm: page_alloc: add __split_page() Kefeng Wang
2026-01-02 18:55   ` Sid Kumar
2025-12-30  7:24 ` [PATCH v5 3/6] mm: cma: kill cma_pages_valid() Kefeng Wang
2025-12-30  7:24 ` [PATCH v5 4/6] mm: page_alloc: add alloc_contig_frozen_{range,pages}() Kefeng Wang
2025-12-31  2:57   ` Zi Yan
2026-01-02 21:05   ` Sid Kumar
2025-12-30  7:24 ` [PATCH v5 5/6] mm: cma: add cma_alloc_frozen{_compound}() Kefeng Wang
2025-12-31  2:59   ` Zi Yan
2026-01-08  4:19   ` Dmitry Baryshkov
2026-01-08  6:57     ` Kefeng Wang
2025-12-30  7:24 ` [PATCH v5 6/6] mm: hugetlb: allocate frozen pages for gigantic allocation Kefeng Wang
2025-12-31  2:50   ` Muchun Song
2025-12-31  3:00   ` Zi Yan
2025-12-30 18:17 ` [PATCH v5 mm-new 0/6] mm: hugetlb: allocate frozen gigantic folio Andrew Morton
2026-01-07 17:31 ` Claudiu Beznea
2026-01-07 18:25   ` Andrew Morton
2026-01-07 18:26   ` Zi Yan
2026-01-07 18:39   ` Mark Brown
2026-01-07 18:50     ` Andrew Morton
2026-01-07 19:38     ` Zi Yan
     [not found]       ` <CGME20260107225819eucas1p2de678d4e810fdbde87192b83033a814c@eucas1p2.samsung.com>
2026-01-07 22:58         ` Marek Szyprowski
2026-01-08  1:05       ` Kefeng Wang
2026-01-08  1:53         ` Kefeng Wang
2026-01-08  3:25           ` Zi Yan
2026-01-08  7:10             ` Kefeng Wang
2026-01-08  9:00       ` Claudiu Beznea
2026-01-08  9:14       ` Konrad Dybcio [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=acf3ae82-2cf3-4c85-bbb9-bbcbe2b7be3c@gmail.com \
    --to=konradybcio@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=broonie@kernel.org \
    --cc=claudiu.beznea@tuxon.dev \
    --cc=david@redhat.com \
    --cc=hannes@cmpxchg.org \
    --cc=jackmanb@google.com \
    --cc=jane.chu@oracle.com \
    --cc=linux-mm@kvack.org \
    --cc=muchun.song@linux.dev \
    --cc=osalvador@suse.de \
    --cc=sidhartha.kumar@oracle.com \
    --cc=vbabka@suse.cz \
    --cc=wangkefeng.wang@huawei.com \
    --cc=willy@infradead.org \
    --cc=ziy@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox