From: Andrew Morton <akpm@linux-foundation.org>
To: Jan Kara <jack@suse.cz>, Ayush Ranjan <ayushr@modal.com>,
Pedro Falcato <pfalcato@suse.de>, Hugh Dickins <hughd@google.com>,
Matthew Wilcox <willy@infradead.org>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
David Hildenbrand <david@kernel.org>,
Gregory Price <gourry@gourry.net>,
linux-mm@kvack.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [BUG] shmem: FALLOC_FL_PUNCH_HOLE vs fault-around race corrupts page cache / rss counters
Date: Thu, 8 Oct 2026 08:31:27 -0700 [thread overview]
Message-ID: <20261008083127.0305bac995e8b84c67e46bbb@linux-foundation.org> (raw)
In-Reply-To: <20261008082304.bc6f4bd6c80fe6432abd4fc5@linux-foundation.org>
On Thu, 8 Oct 2026 08:23:04 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
> A useful next step would be to instrument truncate_cleanup_folio(), e.g. warn
> immediately after unmap_mapping_folio() if folio_mapped() is still true.
> That should distinguish "unmap failed to remove an existing mapping" from
> "some path installed a new mapping afterwards", and narrow this down
> considerably.
does this seem useful? If so I can add it to mm-new/linux-next for a
while.
From: Andrew Morton <akpm@linux-foundation.org>
Subject: mm/truncate: catch shmem folios still mapped after unmap
Date: Thu Oct 8 08:29:04 AM PDT 2026
Instrument truncate_cleanup_folio() to determine where the shmem "still
mapped when deleted" state is introduced.
truncate_inode_folio() calls truncate_cleanup_folio() under the folio
lock, and truncate_cleanup_folio() calls unmap_mapping_folio() before
filemap_remove_folio(). If a shmem folio is still mapped immediately
after that unmap, then the unmap itself failed to remove all mappings (or
a path outside the folio-lock serialization installed one concurrently).
If this warning does not fire but the later "still mapped when deleted"
warning still does, the mapping must have appeared after this point. That
distinguishes the two cases without otherwise changing truncate behavior.
Limit the diagnostic to shmem and dump the folio on the first occurrence.
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/truncate.c | 10 ++++++++++
1 file changed, 10 insertions(+)
--- a/mm/truncate.c~shmem-truncate-unmap-debug
+++ a/mm/truncate.c
@@ -156,6 +156,16 @@ static void truncate_cleanup_folio(struc
if (folio_mapped(folio))
unmap_mapping_folio(folio);
+ /*
+ * Pin down where the shmem "still mapped when deleted" state appears:
+ * if the folio is clear here but mapped at removal, something installed
+ * a mapping after cleanup rather than surviving unmap_mapping_folio().
+ */
+ if (shmem_mapping(folio->mapping) &&
+ WARN_ON_ONCE(folio_mapped(folio)))
+ dump_page(&folio->page,
+ "shmem folio still mapped after unmap_mapping_folio");
+
if (folio_needs_release(folio))
folio_invalidate(folio, 0, folio_size(folio));
_
next prev parent reply other threads:[~2026-10-08 15:31 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-24 6:16 [BUG] shmem: FALLOC_FL_PUNCH_HOLE vs fault-around race corrupts page cache / rss counters Ayush Ranjan
2026-09-24 7:12 ` David Hildenbrand (Arm)
2026-09-24 8:34 ` Pedro Falcato
2026-09-24 9:15 ` Jan Kara
2026-09-25 5:32 ` Ayush Ranjan
2026-09-24 9:30 ` Baolin Wang
2026-09-25 5:33 ` Ayush Ranjan
2026-09-25 5:30 ` Ayush Ranjan
2026-09-25 6:50 ` Ayush Ranjan
2026-10-03 3:31 ` Ayush Ranjan
2026-10-05 5:28 ` Andrew Morton
2026-10-08 9:24 ` Jan Kara
2026-10-08 15:23 ` Andrew Morton
2026-10-08 15:31 ` Andrew Morton [this message]
2026-10-09 6:46 ` Baolin Wang
2026-10-09 8:41 ` Pedro Falcato
2026-10-09 9:20 ` Baolin Wang
2026-10-09 10:14 ` Baolin Wang
2026-10-08 13:07 ` Gregory Price
2026-10-08 7:58 ` Baolin Wang
2026-10-08 9:26 ` Jan Kara
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=20261008083127.0305bac995e8b84c67e46bbb@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=ayushr@modal.com \
--cc=baolin.wang@linux.alibaba.com \
--cc=david@kernel.org \
--cc=gourry@gourry.net \
--cc=hughd@google.com \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=pfalcato@suse.de \
--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