From: Chris J Arges <carges@cloudflare.com>
To: willy@infradead.org, akpm@linux-foundation.org,
william.kucharski@oracle.com
Cc: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, kernel-team@cloudflare.com,
Chris J Arges <carges@cloudflare.com>
Subject: [PATCH RFC 1/1] mm/filemap: handle large folio split race in page cache lookups
Date: Thu, 5 Mar 2026 12:34:33 -0600 [thread overview]
Message-ID: <20260305183438.1062312-2-carges@cloudflare.com> (raw)
In-Reply-To: <20260305183438.1062312-1-carges@cloudflare.com>
We have been hitting VM_BUG_ON_FOLIO(!folio_contains(folio, index)) in
production environments. These machines are using XFS with large folio
support enabled and are under high memory pressure.
From reading the code it seems plausible that folio splits due to memory
reclaim are racing with filemap_fault() serving mmap page faults.
The existing code checks for truncation (folio->mapping != mapping) and
retries, but there does not appear to be equivalent handling for the
split case. The result is:
kernel BUG at mm/filemap.c:3519!
VM_BUG_ON_FOLIO(!folio_contains(folio, index), folio)
This RFC patch extends the existing truncation retry checks to also
cover the case where the folio no longer contains the target index.
Fixes: e292e6d644ce ("filemap: Convert filemap_fault to folio")
Signed-off-by: Chris J Arges <carges@cloudflare.com>
---
mm/filemap.c | 17 ++++++++---------
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/mm/filemap.c b/mm/filemap.c
index 6cd7974d4ada..334d3f700beb 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -1954,13 +1954,13 @@ struct folio *__filemap_get_folio_mpol(struct address_space *mapping,
folio_lock(folio);
}
- /* Has the page been truncated? */
- if (unlikely(folio->mapping != mapping)) {
+ /* Has the page been truncated or split? */
+ if (unlikely(folio->mapping != mapping) ||
+ unlikely(!folio_contains(folio, index))) {
folio_unlock(folio);
folio_put(folio);
goto repeat;
}
- VM_BUG_ON_FOLIO(!folio_contains(folio, index), folio);
}
if (fgp_flags & FGP_ACCESSED)
@@ -2179,10 +2179,9 @@ unsigned find_lock_entries(struct address_space *mapping, pgoff_t *start,
if (!folio_trylock(folio))
goto put;
if (folio->mapping != mapping ||
- folio_test_writeback(folio))
+ folio_test_writeback(folio) ||
+ !folio_contains(folio, xas.xa_index))
goto unlock;
- VM_BUG_ON_FOLIO(!folio_contains(folio, xas.xa_index),
- folio);
} else {
nr = 1 << xas_get_order(&xas);
base = xas.xa_index & ~(nr - 1);
@@ -3570,13 +3569,13 @@ vm_fault_t filemap_fault(struct vm_fault *vmf)
if (!lock_folio_maybe_drop_mmap(vmf, folio, &fpin))
goto out_retry;
- /* Did it get truncated? */
- if (unlikely(folio->mapping != mapping)) {
+ /* Did it get truncated or split? */
+ if (unlikely(folio->mapping != mapping) ||
+ unlikely(!folio_contains(folio, index))) {
folio_unlock(folio);
folio_put(folio);
goto retry_find;
}
- VM_BUG_ON_FOLIO(!folio_contains(folio, index), folio);
/*
* We have a locked folio in the page cache, now we need to check
--
2.43.0
next prev parent reply other threads:[~2026-03-05 18:35 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-05 18:34 [PATCH RFC 0/1] fix for large folio split race in page cache Chris J Arges
2026-03-05 18:34 ` Chris J Arges [this message]
2026-03-05 19:24 ` [PATCH RFC 1/1] mm/filemap: handle large folio split race in page cache lookups 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=20260305183438.1062312-2-carges@cloudflare.com \
--to=carges@cloudflare.com \
--cc=akpm@linux-foundation.org \
--cc=kernel-team@cloudflare.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=william.kucharski@oracle.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox