linux-kernel - Re: WARNING in memory_failure() at include/linux/huge

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: <7bb98650-cb7a-4230-8868-7da2aab5923a@kernel.org>
Date: Wed, 4 Feb 2026 21:31:18 +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:13, Zi Yan wrote:
> On 4 Feb 2026, at 14:55, David Hildenbrand (arm) wrote:
> 
>> On 2/4/26 20:48, Zi Yan wrote:
>>>
>>>
>>> What do you mean? Changing memory failure code to only handle large_rmappable?
>>> large_rmappable is a folio flag, memory failure code should see such
>>
>> Did you mean "should not" ? :)
> 
> Yes.
> 
>>
>>> non-folio but compound things to begin with, IMHO.
>>
>> I would say that we could right now reject in memory failure code any compound pages that do not have PG_large_rmappable set.
>>
>> I have the faint recollection that we don't set PG_large_rmappable on hugetlb folios yet, so they have to identified as well.
> 
> 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 :)

>>>
>>> I think we need to be able to tell between raw page (compound or not),
>>> mappable page (compound or not, especially for those used with vm_insert_*),
>>> and folio.
>>
>> We can't identify (small) folios just yet. We'd need another page flag for that (just like PG_large_rmappable), and we all know how that ends ;)
> 
> 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.

> 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.

> 
>>
>> With Willy's work we'll be able to identify folios reliably.
>>
>> How to deal with that vm_insert_* crap, especially for non-folio pages, is also future work based on that.
> 
> 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.

-- 
Cheers,

David