Re: [PATCH 00/10] convert the majority of file systems to mmap_prepare
Jason Gunthorpe <[email protected]>
| Newsgroups | org.kernel.vger.linux-bcachefs,dev.linux.lists.ntfs3,dev.linux.lists.nvdimm,dev.linux.lists.ocfs2-devel,dev.linux.lists.v9fs,net.sourceforge.lists.linux-f2fs-devel,org.freedesktop.lists.dri-devel,org.infradead.lists.linux-mtd,org.infradead.lists.linux-um,org.kernel.vger.ceph-devel,org.kernel.vger.ecryptfs,org.kernel.vger.linux-block,org.kernel.vger.linux-btrfs,org.kernel.vger.linux-cifs,org.kernel.vger.linux-ext4,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel,org.kernel.vger.linux-nfs,org.kernel.vger.linux-nilfs,org.kernel.vger.linux-unionfs,org.kernel.vger.linux-xfs,org.kvack.linux-mm,org.ozlabs.lists.linux-erofs |
|---|---|
| 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