From: Ackerley Tng <ackerleytng@google.com>
To: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org, kvm@vger.kernel.org,
linux-kselftest@vger.kernel.org
Cc: akpm@linux-foundation.org, david@kernel.org,
lorenzo.stoakes@oracle.com, Liam.Howlett@oracle.com,
vbabka@suse.cz, rppt@kernel.org, surenb@google.com,
mhocko@suse.com, willy@infradead.org, pbonzini@redhat.com,
shuah@kernel.org, ackerleytng@google.com, seanjc@google.com,
shivankg@amd.com, rick.p.edgecombe@intel.com,
yan.y.zhao@intel.com, rientjes@google.com, fvdl@google.com,
jthoughton@google.com, vannapurve@google.com,
pratyush@kernel.org, pasha.tatashin@soleen.com,
kalyazin@amazon.com, tabba@google.com, michael.roth@amd.com
Subject: [RFC PATCH v1 00/10] guest_memfd: Track amount of memory allocated on inode
Date: Mon, 23 Feb 2026 07:04:33 +0000 [thread overview]
Message-ID: <cover.1771826352.git.ackerleytng@google.com> (raw)
Hi,
Currently, guest_memfd doesn't update inode's i_blocks or i_bytes at
all. Hence, st_blocks in the struct populated by a userspace fstat()
call on a guest_memfd will always be 0. This patch series makes
guest_memfd track the amount of memory allocated on an inode, which
allows fstat() to accurately report that on requests from userspace.
The inode's i_blocks and i_bytes fields are updated when the folio is
associated or disassociated from the guest_memfd inode, which are at
allocation and truncation times respectively.
To update inode fields at truncation time, this series implements a
custom truncation function for guest_memfd. An alternative would be to
update truncate_inode_pages_range() to return the number of bytes
truncated or add/use some hook.
Implementing a custom truncation function was chosen to provide
flexibility for handling truncations in future when guest_memfd
supports sources of pages other than the buddy allocator. This
approach of a custom truncation function also aligns with shmem, which
has a custom shmem_truncate_range().
To update inode fields at allocation time, kvm_gmem_get_folio() is
simply augmented such that when a folio is added to the filemap, the
size of the folio is updated into inode fields.
The second patch, to use filemap_alloc_folio() during allocation of
guest_memfd folios, was written as a debugging step to resolve a bug
found by syzbot [1], but turned out to not be the fix. I include it
here because it cleans up the allocation process and provides a nice
foundation for updating inode fields during allocations.
The first patch was separately submitted [2], and provided here since
it is a prerequisite simplication before application of the second
patch.
[1] https://lore.kernel.org/all/29c347bde68ec027259654e8e85371307edf7058.1770148108.git.ackerleytng@google.com/
[2] https://lore.kernel.org/all/20260129172646.2361462-1-ackerleytng@google.com/
Ackerley Tng (10):
KVM: guest_memfd: Don't set FGP_ACCESSED when getting folios
KVM: guest_memfd: Directly allocate folios with filemap_alloc_folio()
mm: truncate: Expose preparation steps for
truncate_inode_pages_final()
KVM: guest_memfd: Implement evict_inode for guest_memfd
mm: Export unmap_mapping_folio() for KVM
mm: filemap: Export filemap_remove_folio()
KVM: guest_memfd: Implement custom truncation function
KVM: guest_memfd: Track amount of memory allocated on inode
KVM: selftests: Wrap fstat() to assert success
KVM: selftests: Test that st_blocks is updated on allocation
include/linux/mm.h | 3 +
mm/filemap.c | 2 +
mm/internal.h | 2 -
mm/memory.c | 2 +
mm/truncate.c | 21 +++-
.../testing/selftests/kvm/guest_memfd_test.c | 32 +++--
.../selftests/kvm/include/kvm_syscalls.h | 2 +
virt/kvm/guest_memfd.c | 116 +++++++++++++++---
8 files changed, 149 insertions(+), 31 deletions(-)
base-commit: b1195183ed42f1522fae3fe44ebee3af437aa000
--
2.53.0.345.g96ddfc5eaa-goog
next reply other threads:[~2026-02-23 7:04 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-23 7:04 Ackerley Tng [this message]
2026-02-23 7:04 ` [RFC PATCH v1 01/10] KVM: guest_memfd: Don't set FGP_ACCESSED when getting folios Ackerley Tng
2026-02-23 7:04 ` [RFC PATCH v1 02/10] KVM: guest_memfd: Directly allocate folios with filemap_alloc_folio() Ackerley Tng
2026-02-23 7:04 ` [RFC PATCH v1 03/10] mm: truncate: Expose preparation steps for truncate_inode_pages_final() Ackerley Tng
2026-02-23 7:04 ` [RFC PATCH v1 04/10] KVM: guest_memfd: Implement evict_inode for guest_memfd Ackerley Tng
2026-02-23 7:04 ` [RFC PATCH v1 05/10] mm: Export unmap_mapping_folio() for KVM Ackerley Tng
2026-02-23 7:04 ` [RFC PATCH v1 06/10] mm: filemap: Export filemap_remove_folio() Ackerley Tng
2026-02-23 7:04 ` [RFC PATCH v1 07/10] KVM: guest_memfd: Implement custom truncation function Ackerley Tng
2026-02-23 7:04 ` [RFC PATCH v1 08/10] KVM: guest_memfd: Track amount of memory allocated on inode Ackerley Tng
2026-02-23 7:04 ` [RFC PATCH v1 09/10] KVM: selftests: Wrap fstat() to assert success Ackerley Tng
2026-02-23 7:04 ` [RFC PATCH v1 10/10] KVM: selftests: Test that st_blocks is updated on allocation Ackerley Tng
2026-02-23 15:23 ` [RFC PATCH v1 00/10] guest_memfd: Track amount of memory allocated on inode David Hildenbrand (Arm)
2026-02-23 23:42 ` Ackerley Tng
2026-02-24 15:26 ` David Hildenbrand (Arm)
2026-02-24 23:08 ` Ackerley Tng
2026-02-25 7:31 ` Ackerley Tng
2026-02-25 9:21 ` David Hildenbrand (Arm)
2026-02-26 7:18 ` Ackerley Tng
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=cover.1771826352.git.ackerleytng@google.com \
--to=ackerleytng@google.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=david@kernel.org \
--cc=fvdl@google.com \
--cc=jthoughton@google.com \
--cc=kalyazin@amazon.com \
--cc=kvm@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=mhocko@suse.com \
--cc=michael.roth@amd.com \
--cc=pasha.tatashin@soleen.com \
--cc=pbonzini@redhat.com \
--cc=pratyush@kernel.org \
--cc=rick.p.edgecombe@intel.com \
--cc=rientjes@google.com \
--cc=rppt@kernel.org \
--cc=seanjc@google.com \
--cc=shivankg@amd.com \
--cc=shuah@kernel.org \
--cc=surenb@google.com \
--cc=tabba@google.com \
--cc=vannapurve@google.com \
--cc=vbabka@suse.cz \
--cc=willy@infradead.org \
--cc=yan.y.zhao@intel.com \
/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.