On 25.01.25 15:20, Matthew Wilcox wrote:
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.
We should also use that approach in
https://lore.kernel.org/all/67812fbd.050a0220.d0267.0030.GAE@xxxxxxxxxx/
Grabbing a temporary page/folio reference also works, but I do not like
it where it can be avoided.
Can you take care of that one as well?
--
Cheers,
David / dhildenb
