diff mbox series

mm: BUG if filemap_alloc_folio gives us a folio with a non-NULL ->private

Message ID 20220513142952.27853-1-jlayton@kernel.org (mailing list archive)
State New, archived
Headers show
Series mm: BUG if filemap_alloc_folio gives us a folio with a non-NULL ->private | expand

Commit Message

Jeff Layton May 13, 2022, 2:29 p.m. UTC
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.

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>
---
 mm/filemap.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

It might not hurt to merge this into mainline. If it pops then we know
something is very wrong.

Comments

Matthew Wilcox May 13, 2022, 2:47 p.m. UTC | #1
On Fri, May 13, 2022 at 10:29:52AM -0400, Jeff Layton wrote:
> 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.

Oh, I meant for this to be a debugging aid for your case, rather than
be something we put into upstream.  If we do find out that the page
allocator is returning pages with page->private non-NULL, we should
discuss what the guarantee is that the page allocator provides -- does
it guarantee that page->private is NULL, or is that something the page
cache should zero out itself.

If we do end up changing filemap_alloc_folio(), we need to remember to
change the one in pagemap.h too.

> 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>
> ---
>  mm/filemap.c | 8 +++++---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> It might not hurt to merge this into mainline. If it pops then we know
> something is very wrong.
> 
> diff --git a/mm/filemap.c b/mm/filemap.c
> index 9a1eef6c5d35..74c3fb062ef7 100644
> --- a/mm/filemap.c
> +++ b/mm/filemap.c
> @@ -990,10 +990,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
> -- 
> 2.36.1
>
diff mbox series

Patch

diff --git a/mm/filemap.c b/mm/filemap.c
index 9a1eef6c5d35..74c3fb062ef7 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -990,10 +990,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