From: Kiryl Shutsemau <kirill@shutemov.name>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: David Hildenbrand <david@kernel.org>,
Ilya Gladyshev <ilya.gladyshev@linux.dev>,
Matthew Wilcox <willy@infradead.org>,
Lorenzo Stoakes <ljs@kernel.org>,
Luis Chamberlain <mcgrof@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux-MM <linux-mm@kvack.org>,
"Paul E. McKenney" <paulmck@kernel.org>
Subject: Re: Improve page refcount scalability
Date: Tue, 13 Oct 2026 23:43:46 +0100 [thread overview]
Message-ID: <as6vBoWQGglxXxb0@thinkstation> (raw)
In-Reply-To: <CAHk-=wjLjgfwgSZ1RDk4YdNFcV0ntosMO5AmBoHD76Zb3HFY7Q@mail.gmail.com>
On Tue, Oct 13, 2026 at 11:43:14AM -0700, Linus Torvalds wrote:
> Comments?
There's a race in filemap_read_rcu_batch(). If the folio is replaced
under us with a new one and then i_size is extended, we can read data
that never got written there:
CPU0 CPU1
filemap_read()
filemap_read_rcu()
filemap_read_rcu_batch()
folio = xas_load() // A
test_bit(PG_rcu_free, A)
xas_reload() == A
fadvise(FADV_DONTNEED)
// A leaves the page cache, its
// free is deferred: A stays valid
write()
// page cache re-populated
// i_size extended
isize = i_size_read()
// i_size is extended
copy_page_to_iter(A)
// we read from old folio
// data that user never wrote
We need to re-check that the folio is still in the page cache after we
get the new i_size. See the patch below.
My branch contains a few more changes that address downstream effects of
RCU-freeing the page cache. But we can come back to that later once we get
agreement on the core mechanism.
diff --git a/mm/filemap.c b/mm/filemap.c
index b85de94a1b6e..0d9fcc35dc64 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -2956,6 +2956,8 @@ static bool filemap_read_rcu_batch(struct kiocb *iocb, struct iov_iter *iter,
isize = i_size_read(inode);
if (pos >= isize)
break;
+ if (xas_reload(&xas) != folio)
+ break;
bytes = min_t(loff_t, isize - pos,
min_t(size_t, iov_iter_count(iter),
PAGE_SIZE - offset));
--
Kiryl Shutsemau / Kirill A. Shutemov
next prev parent reply other threads:[~2026-10-13 22:44 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-13 18:43 Improve page refcount scalability Linus Torvalds
2026-10-13 21:03 ` Matthew Wilcox
2026-10-13 21:26 ` Linus Torvalds
2026-10-13 23:20 ` Paul E. McKenney
2026-10-14 10:36 ` Kiryl Shutsemau
2026-10-14 10:46 ` David Hildenbrand (Arm)
2026-10-13 22:43 ` Kiryl Shutsemau [this message]
2026-10-13 23:39 ` Linus Torvalds
2026-10-14 11:53 ` Kiryl Shutsemau
2026-10-14 0:10 ` Harry Yoo
2026-10-14 1:01 ` Linus Torvalds
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=as6vBoWQGglxXxb0@thinkstation \
--to=kirill@shutemov.name \
--cc=david@kernel.org \
--cc=ilya.gladyshev@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mcgrof@kernel.org \
--cc=paulmck@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=willy@infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.