Re: [PATCH 00/10] convert the majority of file systems to mmap_prepare

Jason Gunthorpe <[email protected]> Fri, 1 Aug 2025 11:00:57 -0300
Newsgroups gmane.comp.file-systems.nilfs.user,gmane.linux.block,gmane.linux.kernel,gmane.comp.freedesktop.xorg.drivers.intel,gmane.comp.video.dri.devel,gmane.linux.file-systems,gmane.linux.kernel.aio.general,gmane.linux.file-systems.union,gmane.linux.kernel.mm,gmane.comp.file-systems.btrfs,gmane.comp.file-systems.ceph.devel,gmane.comp.file-systems.coda.general,gmane.comp.file-systems.ecryptfs.general,gmane.comp.file-systems.ext4,gmane.linux.file-systems.f2fs,gmane.linux.uml.devel,gmane.linux.drivers.mtd,gmane.linux.nfs,gmane.linux.hardware.karma.devel,gmane.linux.kernel.cifs,gmane.network.samba.internals
Message-ID <[email protected]> 
On Mon, Jun 16, 2025 at 08:33:19PM +0100, Lorenzo Stoakes wrote:

> The intent is to gradually deprecate f_op->mmap, and in that vein this
> series coverts the majority of file systems to using f_op->mmap_prepare.

I saw this on lwn and just wanted to give a little bit of thought on
this topic..

It looks to me like we need some more infrastructure to convert
anything that uses remap_pfn/etc in the mmap() callback

I would like to suggest we add a vma->prepopulate() callback which is
where the remap_pfn should go. Once the VMA is finalized and fully
operational the vma_ops have the opportunity to prepopulate any PTEs.

This could then actually be locked properly so it is safe with
concurrent unmap_mapping_range() (current mmap callback is not safe)

Jason