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

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

David Hildenbrand wrote:
[..]
> > However, raises the question if fixing it here is sufficient for other
> > ZONE_DEVICE folio cases. I did not immediately find a place where other
> > ZONE_DEVICE users might be calling prep_compound_page() and leaving
> > stale tail page metadata lying around. Alistair?
> 
> We only have to consider this when splitting folios (putting buddy 
> freeing aside). clear_compound_head() is what to search for.

So I do not think there is a problem for the DEVICE_PRIVATE case since
that hits this comment in free_zone_device_folio()

        /*
         * Note: we don't expect anonymous compound pages yet. Once supported
         * and we could PTE-map them similar to THP, we'd have to clear
         * PG_anon_exclusive on all tail pages.
         */                       

The p2p-dma use case does not map into userspace, and the device-dax
case has static folio order for all potential folios. So I think this
fix is only needed for fsdax.

> We don't need it in mm/hugetlb.c because we'll only demote large folios 
> to smaller-large folios and effectively reset the order/nr_pages for all 
> involved folios.

I also now feel better about a local fs/dax.c fix because clearing
_nr_pages in free_zone_device_folio() would require static folio
metadata cases like device-dax to start re-inializing that field.

I.e. this seems to be the only ZONE_DEVICE case doing this demote to
order-0.