[culling cc list down because for it was insane, +David] (apologies if I cut anybody who wants to be involved in discussion, just being practical here). On Fri, Aug 01, 2025 at 11:00:57AM -0300, Jason Gunthorpe wrote: > 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.. Thanks, sure. > > It looks to me like we need some more infrastructure to convert > anything that uses remap_pfn/etc in the mmap() callback Yes absolutely :) I realised we needed extra infra, and later noticed (and in discussion with others) that remap in particular would be a pain. I wanted to lay the groundwork first, as we could safely do this, convert nearly all file systems to .mmap_prepare(), and get a big win on that, then take it further in the next cycle, which I was planning to do. > > 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. I assume you mean vma->vm_ops->prepopulate ? We also have to think about other places where we prepopulate also, for instance the perf mmap call now prepopulates (ahem that was me). So I do like this as a generalisation. > > This could then actually be locked properly so it is safe with > concurrent unmap_mapping_range() (current mmap callback is not safe) Which lock in particular is problematic? You'd want to hold an rmap write lock to avoid racing zap? > > Jason BTW I'll loop you in on discussion/series here. I think what you outline is likely how this will work. Cheers, Lorenzo
