From: Jan Kara <jack@suse.cz>
To: Ackerley Tng <ackerleytng@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@kernel.org>,
Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
Vlastimil Babka <vbabka@suse.cz>,
Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>,
"Matthew Wilcox (Oracle)" <willy@infradead.org>,
Shuah Khan <shuah@kernel.org>, Jonathan Corbet <corbet@lwn.net>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
seanjc@google.com, rientjes@google.com,
rick.p.edgecombe@intel.com, yan.y.zhao@intel.com,
fvdl@google.com, jthoughton@google.com, vannapurve@google.com,
shivankg@amd.com, michael.roth@amd.com, pratyush@kernel.org,
pasha.tatashin@soleen.com, kalyazin@amazon.com,
tabba@google.com, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linux-fsdevel@vger.kernel.org, linux-kselftest@vger.kernel.org,
linux-doc@vger.kernel.org
Subject: Re: [PATCH RFC v2 3/6] fs: Add .unaccount_folio callback
Date: Thu, 26 Feb 2026 13:31:40 +0100 [thread overview]
Message-ID: <2s33j7wg6ehizvdoz5fggc6kfa5byrs4yg2hk4fvwvfjp7nigo@se7fhyaknqqm> (raw)
In-Reply-To: <20260225-gmem-st-blocks-v2-3-87d7098119a9@google.com>
On Wed 25-02-26 07:20:38, Ackerley Tng wrote:
> Add .unaccount_folio callback to allow filesystems to do accounting-related
> updates to the inode or struct address_space mapping, when the folio is
> about to be removed from the filemap/page_cache.
>
> .free_folio cannot be used since .free_folio cannot assume that struct
> address_space mapping still exists.
I agree .free_folio isn't the right place.
> From the name, .invalidate_folio and .release_folio seem suitable, but
> those are meant only to handle freeing of a folio's private
> data. .release_folio is also not called in the truncation path.
But this I don't quite understand. .invalidate_folio is called when
the file is truncated (or when the whole inode is being evicted from
memory). Filesystem can do whatever it wishes there, not just free folio
private data. Are you pointing at folio_needs_release() check? But you can
mark your mappings with mapping_release_always() - it's there exactly for
such usecases... Am I missing something?
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2026-02-26 12:31 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-25 7:20 [PATCH RFC v2 0/6] guest_memfd: Track amount of memory allocated on inode Ackerley Tng
2026-02-25 7:20 ` [PATCH RFC v2 1/6] KVM: guest_memfd: Don't set FGP_ACCESSED when getting folios Ackerley Tng
2026-02-25 7:20 ` [PATCH RFC v2 2/6] KVM: guest_memfd: Directly allocate folios with filemap_alloc_folio() Ackerley Tng
2026-02-25 7:20 ` [PATCH RFC v2 3/6] fs: Add .unaccount_folio callback Ackerley Tng
2026-02-26 12:31 ` Jan Kara [this message]
2026-02-25 7:20 ` [PATCH RFC v2 4/6] KVM: guest_memfd: Track amount of memory allocated on inode Ackerley Tng
2026-02-25 7:20 ` [PATCH RFC v2 5/6] KVM: selftests: Wrap fstat() to assert success Ackerley Tng
2026-02-25 7:20 ` [PATCH RFC v2 6/6] KVM: selftests: Test that st_blocks is updated on allocation 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=2s33j7wg6ehizvdoz5fggc6kfa5byrs4yg2hk4fvwvfjp7nigo@se7fhyaknqqm \
--to=jack@suse.cz \
--cc=Liam.Howlett@oracle.com \
--cc=ackerleytng@google.com \
--cc=akpm@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=corbet@lwn.net \
--cc=david@kernel.org \
--cc=fvdl@google.com \
--cc=jthoughton@google.com \
--cc=kalyazin@amazon.com \
--cc=kvm@vger.kernel.org \
--cc=linux-doc@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=viro@zeniv.linux.org.uk \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox