On Fri, Jan 24, 2025 at 06:34:23PM -0800, syzbot wrote: > ------------[ cut here ]------------ > WARNING: CPU: 0 PID: 6789 at ./include/linux/mm.h:1228 folio_large_mapcount include/linux/mm.h:1228 [inline] > WARNING: CPU: 0 PID: 6789 at ./include/linux/mm.h:1228 folio_mapcount include/linux/mm.h:1262 [inline] > WARNING: CPU: 0 PID: 6789 at ./include/linux/mm.h:1228 folio_mapped include/linux/mm.h:1273 [inline] > WARNING: CPU: 0 PID: 6789 at ./include/linux/mm.h:1228 page_mapped include/linux/mm.h:1283 [inline] > WARNING: CPU: 0 PID: 6789 at ./include/linux/mm.h:1228 stable_page_flags+0xab5/0xbc0 fs/proc/page.c:132 I'm shocked we haven't seen this before. kpageflags_read() iterates over every PFN in a range, calling pfn_to_page() and then page_folio() on each of them. Since it makes no attempt to establish a refcount on the folio (nor should it), the page/folio can be freed under it. And that's what's happened; when it first looked, this page was part of a slab, and now it's free. What we need to do is memcpy() the page, just like we do in dump_page(). I'll get to it next week.
