Re: WARNING in memory_failure() at include/linux/huge_mm.h:635 triggered

[David Hildenbrand (arm)]

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@xxxxxxxxxx/
> >
> > 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