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.
Reported-by: default avatarDave Chinner <david@fromorbit.com>
Reported-by: default avatarBrian Foster <bfoster@redhat.com>
Debugged-by: default avatarBrian Foster <bfoster@redhat.com>
Tested-by: default avatarBrian Foster <bfoster@redhat.com>
Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
Fixes: cbd59c48 ("mm/filemap: use head pages in generic_file_buffered_read")
Cc: stable@vger.kernel.org
Signed-off-by: default avatarMatthew Wilcox (Oracle) <willy@infradead.org>
parent 5ccc944d
......@@ -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;
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment