On 3/20/26 23:39, 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. > > Update the mmap_prepare documentation to describe the mapped hook and make > it clear what its intended use is. > > The vm_ops->mapped() call is handled by the mmap complete logic to ensure > the same code paths are handled by both the compatibility and VMA layers. > > Additionally, update VMA userland test headers to reflect the change. > > Signed-off-by: Lorenzo Stoakes (Oracle) <[email protected]>
Acked-by: Vlastimil Babka (SUSE) <[email protected]>
