Re: [syzbot] [fs?] WARNING in stable_page_flags

[David Hildenbrand <david@redhat.com>]

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@google.com/

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