[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 15800334147b3cdf6f098b84306412f0e1130fab..c7a1507206b1befb351c5fabdedc7333c4546f5c 100644 (file)
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -964,10 +964,12 @@ struct folio *filemap_alloc_folio(gfp_t gfp, unsigned int order)
                        n = cpuset_mem_spread_node();
                        folio = __folio_alloc_node(gfp, order, n);
                } while (!folio && read_mems_allowed_retry(cpuset_mems_cookie));
-
-               return folio;
+       } else {
+               folio = folio_alloc(gfp, order);
        }
-       return folio_alloc(gfp, order);
+       if (folio)
+               VM_BUG_ON_FOLIO(folio->private, folio);
+       return folio;
 }
 EXPORT_SYMBOL(filemap_alloc_folio);
 #endif