On 27/11/2025 19:04, Mike Rapoport wrote:
On Thu, Nov 27, 2025 at 11:19:35AM +0000, Nikita Kalyazin wrote:
On 27/11/2025 10:36, Mike Rapoport wrote:
On Wed, Nov 26, 2025 at 04:49:31PM +0000, Nikita Kalyazin wrote:
On 25/11/2025 18:38, Mike Rapoport wrote:
From: "Mike Rapoport (Microsoft)" <[email protected]>
+#ifdef CONFIG_USERFAULTFD
+static struct folio *kvm_gmem_get_folio(struct inode *inode, pgoff_t pgoff)
We have to name it differently, otherwise it clashes with the existing one
in this file.
It's all David's fault! ;-P
How about kvm_gmem_get_prepared_folio() ?
I'm afraid it may not be ideal due to preparedness tracking being removed
from guest_memfd at some point [1]. Would it be too bad to add an
indication to userfaultfd in the name somehow given that it's already
guarded by the config?
Hmm, shmem also has this clash. There I picked shmem_get_folio_noalloc()
because that describes well what it does: lookup folio in the page cache,
grab it if it's there or return -ENOENT if it's missing.
That's also what hugetlb does for uffd minor fault.
The guest_memfd implementation I copied from one of the older postings
allocates the folio if it's not in the page cache and it seems to me that
it also should only look up existing folios to keep uffd minor semantics
uniform.
I can't see a reason for guest_memfd to deviate from shmem and hugetlb
here so makes sense to me.
Then it makes sense also to name the vm_ops method get_folio_noalloc().
--
Sincerely yours,
Mike.
