On Fri, Mar 20, 2026 at 07:26:37PM +0100, Vlastimil Babka (SUSE) wrote: > On 3/19/26 19:23, Lorenzo Stoakes (Oracle) wrote: > > Previously, when a driver needed to do something like establish a > > reference count, it could do so in the mmap hook in the knowledge that the > > mapping would succeed. > > > > With the introduction of f_op->mmap_prepare this is no longer the case, as > > it is invoked prior to actually establishing the mapping. > > > > mmap_prepare is not appropriate for this kind of thing as it is called > > before any merge might take place, and after which an error might occur > > meaning resources could be leaked. > > > > To take this into account, introduce a new vm_ops->mapped callback which > > is invoked when the VMA is first mapped (though notably - not when it is > > merged - which is correct and mirrors existing mmap/open/close behaviour). > > > > We do better that vm_ops->open() here, as this callback can return an > > error, at which point the VMA will be unmapped. > > > > Note that vm_ops->mapped() is invoked after any mmap action is complete > > (such as I/O remapping). > > > > We intentionally do not expose the VMA at this point, exposing only the > > fields that could be used, and an output parameter in case the operation > > needs to update the vma->vm_private_data field. > > > > In order to deal with stacked filesystems which invoke inner filesystem's > > mmap() invocations, add __compat_vma_mapped() and invoke it on vfs_mmap() > > (via compat_vma_mmap()) to ensure that the mapped callback is handled when > > an mmap() caller invokes a nested filesystem's mmap_prepare() callback. > > > > We can now also remove call_action_complete() and invoke > > mmap_action_complete() directly, as we separate out the rmap lock logic. > > > > The rmap lock logic, which was added in order to keep hugetlb working (!) > > to allow for the rmap lock to be held longer, needs to be propagated to the > > error paths on mmap complete and mapped hook error paths. > > > > This is because do_munmap() might otherwise deadlock with the rmap being > > held, so instead we unlock at the point of unmap. > > Hmm but that was also true prior to this series? So is this a bugfix? Should > it be a stable hotfix done outside of the series before the refactoring?
Yup, will send a hotfix. Thanks, Lorenzo
