"David Hildenbrand (Arm)" <[email protected]> writes: > On 2/23/26 08:04, Ackerley Tng wrote: >> 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(). > > Just wondered how shmem does it: it's through > dquot_alloc_block_nodirty() / dquot_free_block_nodirty(). > > It's a shame we can't just use folio_free().
Yup, Hugh pointed out that struct address_space *mapping (and inode) may already have been freed by the time .free_folio() is called [1]. [1] https://lore.kernel.org/all/[email protected]/ > Could we maybe have a > different callback (when the mapping is still guaranteed to be around) > from where we could update i_blocks on the freeing path? Do you mean that we should add a new callback to struct address_space_operations? .invalidate_folio semantically seems suitable. This is called from truncate_cleanup_folio() and is conditioned on folio_needs_release(). guest_memfd could make itself need release, but IIUC that would cause a NULL pointer dereference in filemap_release_folio() since try_to_free_buffers() -> drop_buffers() will dereference folio->private. >From the name, .release_folio sounds eligible, but this is meant for releasing data attached to a folio, not quite the same as updating inode fields. This is also not called in the truncation path. > > -- > Cheers, > > David
