Re: [BUG Report] 6.15-rc1 RIP: 0010:__lruvec_stat_mod_folio+0x7e/0x250

[Dan Williams <dan.j.williams@intel.com>]

David Hildenbrand wrote:
[..]
> > ^ That's different:  locked|uptodate. Other page flags arriving here are
> > not locked | uptodate.
> > 
> > Git bisect says this is first bad patch (6.14 --> 6.15-rc1)
> > 4996fc547f5b ("mm: let _folio_nr_pages overlay memcg_data in first tail page")
> > 
> > Experimenting a bit with the patch, UN-defining NR_PAGES_IN_LARGE_FOLIO,
> > avoids the problem.
> > 
> > The way that patch is reusing memory in tail pages and the fact that it
> > only fails in XFS (not ext4) suggests the XFS is depending on tail pages
> > in a way that ext4 does not.
> 
> IIRC, XFS supports large folios but ext4 does not. But I don't really 
> know how that interacts with DAX (if the same thing applies). Ordinary 
> XFS large folio tests seem to work just fine, so the question is what 
> DAX-specific is happening here.

So with fsdax large-folios come from large-extents. I.e. you can have
large fsdax folios regardless of whether the filesystem supports large
folios for page-cache mappings. The dax unit tests have an easier time
getting XFS to create large extents than ext4.

> When we free large folios back to the buddy, we set "folio->_nr_pages = 
> 0", to make the "page->memcg_data" check in page_bad_reason() happy. 
> Also, just before the large folio split for ordinary large folios, we 
> set "folio->_nr_pages = 0".

Ah, yes, that is definitely missing in the fsdax case.