From: Pedro Falcato <pfalcato@suse.de>
To: Gregory Price <gourry@gourry.net>
Cc: linux-mm@kvack.org, akpm@linux-foundation.org, hughd@google.com,
david@kernel.org, ljs@kernel.org, Liam.Howlett@oracle.com,
vbabka@kernel.org, rppt@kernel.org, surenb@google.com,
mhocko@suse.com, baolin.wang@linux.alibaba.com,
linux-kernel@vger.kernel.org, kernel-team@meta.com,
stable@vger.kernel.org
Subject: Re: [PATCH] mm/shmem: use invalidate_lock to fix hole-punch race
Date: Thu, 26 Mar 2026 17:07:42 +0000 [thread overview]
Message-ID: <jm5rmcwiauy2fn6fvj6cjowiu2dudjndhhlcd2tm275ibmos5i@dwxwchbs24ko> (raw)
In-Reply-To: <20260326162611.693539-1-gourry@gourry.net>
On Thu, Mar 26, 2026 at 11:26:11AM -0500, Gregory Price wrote:
> Inflating a VM's balloon while vhost-user-net fork+exec's a helper
> triggers "still mapped when deleted" on the memfd backing guest RAM:
>
> BUG: Bad page cache in process __balloon pfn:6520704
> page dumped because: still mapped when deleted
> ...
> shmem_undo_range+0x3fa/0x570
> shmem_fallocate+0x366/0x4d0
> vfs_fallocate+0x13c/0x310
>
> This BUG also resulted in guests seeing stale mappings backed by a
> zeroed page, causing guest kernel panics. I was unable to trace that
> specific interaction, but it appears to be related to THP splitting.
>
> Two races allow PTEs to be re-installed for a folio that fallocate
> is about to remove from page cache:
Hmm, I don't see how your patch fixes anything.
>
> Race 1 — fault-around (filemap_map_pages):
>
> fallocate fault-around fork
> -------- ------------ ----
> set i_private
> unmap_mapping_range()
> # zaps PTEs
> filemap_map_pages()
> # re-maps folio!
> dup_mmap()
> # child VMA
> # in tree
> shmem_undo_range()
> lock folio
> unmap_mapping_folio()
spin_lock(ptl);
> # child VMA:
> # no PTE, skip
spin_unlock(ptl);
> copy_page_range()
spin_lock(dst_ptl);
spin_lock(src_ptl);
/* does not copy PTE. either
* we find a zapped PTE, or unmap_mapping_folio()
* finds two mappings instead of one. */
> # copies PTE
> # parent VMA:
> # zaps PTE
> filemap_remove_folio()
> # mapcount=1, BUG!
>
> filemap_map_pages() is called directly as .map_pages, bypassing
> shmem_fault()'s i_private synchronization.
>
> Race 2 — shmem_fault TOCTOU:
>
> fallocate shmem_fault
> -------- -----------
> check i_private → NULL
> set i_private
> unmap_mapping_range()
> # zaps PTEs
> shmem_get_folio_gfp()
> # finds folio in cache
> finish_fault()
> # installs PTE
> shmem_undo_range()
> truncate_inode_folio()
truncate_inode_folio() zaps the PTEs, thus mapcount = 0.
shmem folio is locked by both truncate and shmem_fault().
> # mapcount=1, BUG!
>
> Fix both races with invalidate_lock.
>
I don't see what you're seeing? Note that both map_pages and fault()
take the folio lock (map_pages does a trylock) to exclude against truncate
as well.
--
Pedro
next prev parent reply other threads:[~2026-03-26 17:07 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-26 16:26 Gregory Price
2026-03-26 17:07 ` Pedro Falcato [this message]
2026-03-26 18:37 ` Gregory Price
2026-03-26 19:16 ` Pedro Falcato
2026-03-26 19:48 ` Gregory Price
2026-03-27 4:35 ` Gregory Price
2026-03-26 19:21 ` Matthew Wilcox
2026-03-26 20:09 ` Gregory Price
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=jm5rmcwiauy2fn6fvj6cjowiu2dudjndhhlcd2tm275ibmos5i@dwxwchbs24ko \
--to=pfalcato@suse.de \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=david@kernel.org \
--cc=gourry@gourry.net \
--cc=hughd@google.com \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=rppt@kernel.org \
--cc=stable@vger.kernel.org \
--cc=surenb@google.com \
--cc=vbabka@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