Message-ID: <29f79411-3ec9-4e03-a1f1-2869164dccd3@kernel.org>
Date: Wed, 4 Feb 2026 22:14:50 +0100
From: "David Hildenbrand (arm)" <david@...nel.org>
To: Zi Yan <ziy@...dia.com>
Cc: 是参差 <shicenci@...il.com>, linux-mm@...ck.org,
 linmiaohe@...wei.com, akpm@...ux-foundation.org,
 linux-kernel@...r.kernel.org, Matthew Wilcox <willy@...radead.org>
Subject: Re: WARNING in memory_failure() at include/linux/huge_mm.h:635
 triggered

On 2/4/26 21:45, Zi Yan wrote:
> On 4 Feb 2026, at 15:31, David Hildenbrand (arm) wrote:
> 
>> On 2/4/26 21:13, Zi Yan wrote:
>>>
>>>
>>> Yes.
>>>
>>>
>>> Right. My patchset[1] is trying to add it, since hugetlb is used as a folio
>>> in most places and large_rmappable is a folio flag.
>>>
>>>
>>> [1] https://lore.kernel.org/all/20260130034818.472804-1-ziy@nvidia.com/
>>
>> Still on my todo list :)
> 
> Sure. Wait for your input there. :)

Hoping I'll be able to dig through that pile in my inbox fairly quickly
throughout the next days.

Thanks for all the review you did why I was not paying a lot of attention.

> 
>>
>>>
>>> Yes, I am thinking about removing mapcount in struct page to achieve that.
>>
>> On my todo list :) Stupid CONFIG_PAGE_MAPCOUNT that is still around and stupid partial-mapping handling.
>>
>> I worked on this after LPC but was distracted by PTO :D
>>
>>> And only pages used for vm_insert_*() and folios need mapcount.
>>
>> vm_insert_*() won't need it for non-folio things. Only folios. We just have to teach the zap code to also leave the mapcount of these non-folio things alone. IOW, identify them when we map/unmap as "not folio" and not touch the mapcount.
> 
> Oh, that sounds great. I thought I would need to convert all drive code
> that does vm_insert_*() to use folio.

Heh, no. We really just have to identify them when mapping and unmapping them.
"these are not folios".

> Basically, I hit
> __folio_large_mapcount_sanity_checks() on _mm_id_mapcount when I moved
> _mm_id_mapcount and friends from prep_compound_page() to page_rmappable_folio().

Yes, exact same issue.

I ran into something similar in the past and documented it in __folio_rmap_sanity_checks():

	/*
	 * TODO: we get driver-allocated folios that have nothing to do with
	 * the rmap using vm_insert_page(); therefore, we cannot assume that
	 * folio_test_large_rmappable() holds for large folios. We should
	 * handle any desired mapcount+stats accounting for these folios in
	 * VM_MIXEDMAP VMAs separately, and then sanity-check here that
	 * we really only get rmappable folios.
	 */

should have been "for these pages" now that it's clear that not all pages
are/will-be folios.

I added an rmappable check in there back then but found out about the other
compound pages.


> IIUC, __folio_add_file_rmap() can just return if a non-folio compound page
> is encountered. Of course, remove part needs to do the same.

We should never call that code, because ... we don't won't really have a folio :)

With Willy's changes, page_folio() will return NULL for things that are not a folio
IIRC.


> 
> 
>>
>>> Code
>>> uses vm_insert_*() on pages would probably have a struct mappable_page
>>> with mapcount.
>>
>> I don't think we'll need a mapcount for them. Only for folios.
>>
>>>
>>>
>>> I think it might the other way around. memdesc does not have mapcount,
>>> if we do not have a separate struct for these mappable pages now,
>>> what do we use at memdesc time? folio?
>>
>> Folios will have mapcount related information, yes. Long term, memdescs will for sure not have any.
>>
>> Real fun begins once we start messing with refcounts. vm_insert_*() will be "fun" on non-folio things.
> 
> Yeah, maybe we will refcounts for every used memdescs. But who knows.

Some of these things should probably be frozen pages and use a different interface
then. A bunch of hard nuts to crack.

-- 
Cheers,

David

Powered by blists - more mailing lists