Since commit c84bf6dd2b83 ("mm: introduce new .mmap_prepare() file
callback"), The f_op->mmap hook has been deprecated in favour of
f_op->mmap_prepare.This was introduced in order to make it possible for us to eventually eliminate the f_op->mmap hook which is highly problematic as it allows drivers and filesystems raw access to a VMA which is not yet correctly initialised. This hook also introduced complexity for the memory mapping operation, as we must correctly unwind what we do should an error arises. Overall this interface being so open has caused significant problems for us, including security issues, it is important for us to simply eliminate this as a source of problems. Therefore this series continues what was established by extending the functionality further to permit more drivers and filesystems to use mmap_prepare. We start by udpating some existing users who can use the mmap_prepare functionality as-is. We then introduce the concept of an mmap 'action', which a user, on mmap_prepare, can request to be performed upon the VMA: * Nothing - default, we're done * Remap PFN - perform PFN remap with specified parameters * Insert mixed - Insert a linear PFN range as a mixed map * Insert mixed pages - Insert a set of specific pages as a mixed map * Custom action - Should rarely be used, for operations that are truly custom. A hook is invoked. By setting the action in mmap_prepare, this alows us to dynamically decide what to do next, so if a driver/filesystem needs to determine whether to e.g. remap or use a mixed map, it can do so then change which is done. This significantly expands the capabilities of the mmap_prepare hook, while maintaining as much control as possible in the mm logic. In the custom hook case, which unfortunately we have to provide for the obstinate drivers which insist on doing 'interesting' things, we make it possible for them to invoke mmap actions themselves via mmap_action_prepare() (to be called in mmap_prepare as necessary) and mmap_action_complete() (to be called in the custom hook). This way, we keep as much logic in generic code as possible even in the custom case. The point at which the VMA is accessible it is safe for it to be manipulated as it will already be fully established in the maple tree and error handling can be simplified to unmapping the VMA. We split remap_pfn_range*() functions which allow for PFN remap (a typical mapping prepopulation operation) split between a prepare/complete step, as well as io_mremap_pfn_range_prepare, complete for a similar purpose. >From there we update various mm-adjacent logic to use this functionality as a first set of changes, as well as resctl and cramfs filesystems to round off the non-stacked filesystem instances. We also add success and error hooks for post-action processing for e.g. output debug log on success and filtering error codes. v2: * Propagated tags, thanks everyone! :) * Refactored resctl patch to avoid assigned-but-not-used variable. * Updated resctl change to not use .mmap_abort as discussed with Jason. * Removed .mmap_abort as discussed with Jason. * Removed references to .mmap_abort from documentation. * Fixed silly VM_WARN_ON_ONCE() mistake (asserting opposite of what we mean to) as per report from Alexander. * Fixed relay kerneldoc error. * Renamed __mmap_prelude to __mmap_setup, keep __mmap_complete the same as per David. * Fixed docs typo in mmap_complete description + formatted bold rather than capitalised as per Randy. * Eliminated mmap_complete and rework into actions specified in mmap_prepare (via vm_area_desc) which therefore eliminates the driver's ability to do anything crazy and allows us to control generic logic. * Added helper functions for these - vma_desc_set_remap(), vma_desc_set_mixedmap(). * However unfortunately had to add post action hooks to vm_area_desc, as already hugetlbfs for instance needs to access the VMA to function correctly. It is at least the smallest possible means of doing this. * Updated VMA test logic, the stacked filesystem compatibility layer and documentation to reflect this. * Updated hugetlbfs implementation to use new approach, and refactored to accept desc where at all possible and to do as much as possible in .mmap_prepare, and the minimum required in the new post_hook callback. * Updated /dev/mem and /dev/zero mmap logic to use the new mechanism. * Updated cramfs, resctl to use the new mechanism. * Updated proc_mmap hooks to only have proc_mmap_prepare. * Updated the vmcore implementation to use the new hooks. * Updated kcov to use the new hooks. * Added hooks for success/failure for post-action handling. * Added custom action hook for truly custom cases. * Abstracted actions to separate type so we can use generic custom actions in custom handlers when necessary. * Added callout re: lock issue raised in https://lore.kernel.org/linux-mm/20250801162930.gb184...@nvidia.com/ as per discussion with Jason. v1: https://lore.kernel.org/all/cover.1757329751.git.lorenzo.stoa...@oracle.com/ Lorenzo Stoakes (16): mm/shmem: update shmem to use mmap_prepare device/dax: update devdax to use mmap_prepare mm: add vma_desc_size(), vma_desc_pages() helpers relay: update relay to use mmap_prepare mm/vma: rename __mmap_prepare() function to avoid confusion mm: add remap_pfn_range_prepare(), remap_pfn_range_complete() mm: introduce io_remap_pfn_range_[prepare, complete]() mm: add ability to take further action in vm_area_desc doc: update porting, vfs documentation for mmap_prepare actions mm/hugetlbfs: update hugetlbfs to use mmap_prepare mm: update mem char driver to use mmap_prepare mm: update resctl to use mmap_prepare mm: update cramfs to use mmap_prepare fs/proc: add the proc_mmap_prepare hook for procfs fs/proc: update vmcore to use .proc_mmap_prepare kcov: update kcov to use mmap_prepare Documentation/filesystems/porting.rst | 5 + Documentation/filesystems/vfs.rst | 4 + arch/csky/include/asm/pgtable.h | 5 + arch/mips/alchemy/common/setup.c | 28 ++++- arch/mips/include/asm/pgtable.h | 10 ++ arch/s390/kernel/crash_dump.c | 6 +- arch/sparc/include/asm/pgtable_32.h | 29 ++++- arch/sparc/include/asm/pgtable_64.h | 29 ++++- drivers/char/mem.c | 75 ++++++------ drivers/dax/device.c | 32 +++-- fs/cramfs/inode.c | 46 ++++---- fs/hugetlbfs/inode.c | 30 +++-- fs/ntfs3/file.c | 2 +- fs/proc/inode.c | 12 +- fs/proc/vmcore.c | 54 ++++++--- fs/resctrl/pseudo_lock.c | 22 ++-- include/linux/hugetlb.h | 9 +- include/linux/hugetlb_inline.h | 15 ++- include/linux/mm.h | 83 ++++++++++++- include/linux/mm_types.h | 61 ++++++++++ include/linux/proc_fs.h | 1 + include/linux/shmem_fs.h | 3 +- include/linux/vmalloc.h | 10 +- kernel/kcov.c | 42 ++++--- kernel/relay.c | 33 +++--- mm/hugetlb.c | 77 +++++++----- mm/memory.c | 128 ++++++++++++-------- mm/secretmem.c | 2 +- mm/shmem.c | 49 ++++++-- mm/util.c | 150 ++++++++++++++++++++++- mm/vma.c | 74 ++++++++---- mm/vmalloc.c | 16 ++- tools/testing/vma/vma_internal.h | 164 +++++++++++++++++++++++++- 33 files changed, 1002 insertions(+), 304 deletions(-) -- 2.51.0
