From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
To: David Howells <dhowells@redhat.com>,
Jeff Layton <jlayton@kernel.org>,
linux-fsdevel@vger.kernel.org
Cc: "Matthew Wilcox (Oracle)" <willy@infradead.org>
Subject: [PATCH] mm/readahead: Handle ractl nr_pages being modified
Date: Tue, 20 Apr 2021 21:01:15 +0100 [thread overview]
Message-ID: <20210420200116.3715790-1-willy@infradead.org> (raw)
The BUG_ON that checks whether the ractl is still in sync with the
local variables can trigger under some fairly unusual circumstances.
Remove the BUG_ON and resync the loop counter after every call to
read_pages().
One way I've seen to trigger it is:
- Start out with a partially populated range in the page cache
- Allocate some pages and run into an existing page
- Send the read request off to the filesystem
- The page we ran into is removed from the page cache
- readahead_expand() succeeds in expanding upwards
- Return to page_cache_ra_unbounded() and we hit the BUG_ON, as nr_pages
has been adjusted upwards.
Reported-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
---
mm/readahead.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/readahead.c b/mm/readahead.c
index f02dbebf1cef..989a8e710100 100644
--- a/mm/readahead.c
+++ b/mm/readahead.c
@@ -198,8 +198,6 @@ void page_cache_ra_unbounded(struct readahead_control *ractl,
for (i = 0; i < nr_to_read; i++) {
struct page *page = xa_load(&mapping->i_pages, index + i);
- BUG_ON(index + i != ractl->_index + ractl->_nr_pages);
-
if (page && !xa_is_value(page)) {
/*
* Page already present? Kick off the current batch
@@ -210,6 +208,7 @@ void page_cache_ra_unbounded(struct readahead_control *ractl,
* not worth getting one just for that.
*/
read_pages(ractl, &page_pool, true);
+ i = ractl->_index + ractl->_nr_pages - index;
continue;
}
@@ -223,6 +222,7 @@ void page_cache_ra_unbounded(struct readahead_control *ractl,
gfp_mask) < 0) {
put_page(page);
read_pages(ractl, &page_pool, true);
+ i = ractl->_index + ractl->_nr_pages - index;
continue;
}
if (i == nr_to_read - lookahead_size)
--
2.30.2
next reply other threads:[~2021-04-20 20:02 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-20 20:01 Matthew Wilcox (Oracle) [this message]
2021-04-20 20:06 ` [PATCH] mm/readahead: Handle ractl nr_pages being modified Matthew Wilcox
2021-04-20 20:12 ` Jeff Layton
2021-04-20 21:03 ` Matthew Wilcox
2021-04-21 16:49 ` Jeff Layton
2021-04-21 10:34 ` David Howells
2021-04-21 12:27 ` Matthew Wilcox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210420200116.3715790-1-willy@infradead.org \
--to=willy@infradead.org \
--cc=dhowells@redhat.com \
--cc=jlayton@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).