[DO NOT MERGE] mm: BUG if filemap_alloc_folio gives us a folio with a non-NULL -...

We've seen some instances where we call __filemap_get_folio and get back
one with a ->private value that is non-NULL. Let's have the allocator
bug if that happens.

For now, let's just put this into the testing kernel. We can let Willy
decide if he wants it in mainline.

URL: https://tracker.ceph.com/issues/55421
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Xiubo Li <xiubli@redhat.com>
Cc: Luís Henriques <lhenriques@suse.de>
Signed-off-by: Jeff Layton <jlayton@kernel.org>

diff --git a/mm/filemap.c b/mm/filemap.c
index 7b90cbeb4a1adfe44da53ea76a60ccc2f0e9609d..dd1876f66673656765f6cee96633e8e7027384e0 100644 (file)
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -1001,10 +1001,12 @@ struct folio *filemap_alloc_folio_noprof(gfp_t gfp, unsigned int order)
                        n = cpuset_mem_spread_node();
                        folio = __folio_alloc_node_noprof(gfp, order, n);
                } while (!folio && read_mems_allowed_retry(cpuset_mems_cookie));
-
-               return folio;
+       } else {
+               folio = folio_alloc_noprof(gfp, order);
        }
-       return folio_alloc_noprof(gfp, order);
+       if (folio)
+               VM_BUG_ON_FOLIO(folio->private, folio);
+       return folio;
 }
 EXPORT_SYMBOL(filemap_alloc_folio_noprof);
 #endif