FAILED: patch "[PATCH] filemap: Handle sibling entries in filemap_get_read_batch()" failed to apply to 5.15-stable tree
Subsystems (3)
[email protected]
maintainerThe patch below does not apply to the 5.15-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From cb995f4eeba9d268fd4b56c2423ad6c1d1ea1b82 Mon Sep 17 00:00:00 2001
From: "Matthew Wilcox (Oracle)" <[email protected]>
Date: Fri, 17 Jun 2022 20:00:17 -0400
Subject: [PATCH] filemap: Handle sibling entries in filemap_get_read_batch()
If a read races with an invalidation followed by another read, it is possible for a folio to be replaced with a higher-order folio. If that happens, we'll see a sibling entry for the new folio in the next iteration of the loop. This manifests as a NULL pointer dereference while holding the RCU read lock.
Handle this by simply returning. The next call will find the new folio and handle it correctly. The other ways of handling this rare race are more complex and it's just not worth it.
mm/filemap.c +2 -0
@@ -2385,6 +2385,8 @@ static void filemap_get_read_batch(struct address_space *mapping,continue ;if (xas.xa_index > max ||xa_is_value (folio))break ; +if (xa_is_sibling (folio)) +break ;if (!folio_try_get_rcu (folio)) goto retry;
Matthew Wilcox
maintainerQuoted 5 lines · On Sat, Jun 25, 2022 at 04:44:59PM +0200, [email protected] wrote:
The patch below does not apply to the 5.15-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.
Compile-tested only, but it's fairly straightforward (if you understand how the code mutated over time)
mm/filemap.c +2 -0
@@ -2341,6 +2341,8 @@ static void filemap_get_read_batch(struct address_space *mapping,continue ;if (xas.xa_index > max ||xa_is_value (head))break ; +if (xa_is_sibling (head)) +break ;if (!page_cache_get_speculative (head)) goto retry;
Quoted 44 lines
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
Quoted 1 line
From
cb995f4eeba9d268fd4b56c2423ad6c1d1ea1b82Mon Sep 17 00:00:00 2001From: "Matthew Wilcox (Oracle)" <[email protected]>
Date: Fri, 17 Jun 2022 20:00:17 -0400
Subject: [PATCH] filemap: Handle sibling entries infilemap_get_read_batch()If a read races with an invalidation followed by another read, it is possible for a folio to be replaced with a higher-order folio. If that happens, we'll see a sibling entry for the new folio in the next iteration of the loop. This manifests as a NULL pointer dereference while holding the RCU read lock.
Handle this by simply returning. The next call will find the new folio and handle it correctly. The other ways of handling this rare race are more complex and it's just not worth it.
Reported-by Dave Chinner <[email protected]>Reported-by Brian Foster <[email protected]>Debugged-by Brian Foster <[email protected]>Tested-by Brian Foster <[email protected]>Reviewed-by Brian Foster <[email protected]>Fixes cbd59c48ae2b ("mm/filemap: use head pages in generic_file_buffered_read")Signed-off-by Matthew Wilcox (Oracle) <[email protected]>mm/filemap.c +2
-0@@ -2385,6 +2385,8 @@ static void filemap_get_read_batch(struct address_space *mapping,continue ;if (xas.xa_index > max ||xa_is_value (folio))break ; +if (xa_is_sibling (folio)) +break ;if (!folio_try_get_rcu (folio)) goto retry;