Message-ID: <cover.1756920635.git.lorenzo.stoakes@oracle.com>
Date: Wed,  3 Sep 2025 18:48:40 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Alexander Viro <viro@...iv.linux.org.uk>,
        Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>,
        David Hildenbrand <david@...hat.com>,
        "Liam R . Howlett" <Liam.Howlett@...cle.com>,
        Vlastimil Babka <vbabka@...e.cz>, Mike Rapoport <rppt@...nel.org>,
        Suren Baghdasaryan <surenb@...gle.com>, Michal Hocko <mhocko@...e.com>,
        Jann Horn <jannh@...gle.com>, Pedro Falcato <pfalcato@...e.de>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org
Subject: [PATCH v2 0/2] mm: do not assume file == vma->vm_file in compat_vma_mmap_prepare()

As part of the efforts to eliminate the problematic f_op->mmap callback,
a new callback - f_op->mmap_prepare was provided.

While we are converting these callbacks, we must deal with 'stacked'
filesystems and drivers - those which in their own f_op->mmap callback
invoke an inner f_op->mmap callback.

To accomodate for this, a compatibility layer is provided that, via
vfs_mmap(), detects if f_op->mmap_prepare is provided and if so, generates
a vm_area_desc containing the VMA's metadata and invokes the call.

So far, we have provided desc->file equal to vma->vm_file. However this is
not necessarily valid, especially in the case of stacked drivers which wish
to assign a new file after the inner hook is invoked.

To account for this, we adjust vm_area_desc to have both file and vm_file
fields. The .vm_file field is strictly set to vma->vm_file (or in the case
of a new mapping, what will become vma->vm_file).

However, .file is set to whichever file vfs_mmap() is invoked with when
using the compatibilty layer.

Therefore, if the VMA's file needs to be updated in .mmap_prepare,
desc->vm_file should be assigned, whilst desc->file should be read.

No current f_op->mmap_prepare users assign desc->file so this is safe to
do.

This makes the .mmap_prepare callback in the context of a stacked
filesystem or driver completely consistent with the existing .mmap
implementations.

While we're here, we do a few small cleanups, and ensure that we const-ify
things correctly in the vm_area_desc struct to avoid hooks accidentally
trying to assign fields they should not.

v2:
* Refer to 'stacked' mmap callers as per Brauner.
* Updated comments etc. as per Liam.
* Add new vm_file field intended to be mutable as a result of discussion with
  Liam.
* Made desc->file a 'const struct file *const' pointer so a user won't
  mistakenly assign to it.
* While we're here - Made desc->mm const (and updated the one case where
  desc->mm being const matters - mlock_future_ok(), invoked by
  secretmem_mmap_prepare()) and also set const for assignment to ensure hook
  user doesn't incorrectly consider this field to be updateable.
* Separated changes to VMA descriptor logic into separate commit.
* Consistently refer to 'filesystems' not 'file systems'.
* Rearranged checks in set_vma_from_desc() putting the possibly desc->xxx field
  first as this seems clearer.
* Fix the kerneldoc error for __compat_vma_mmap_prepare().
* Update comments as necessary.

v1:
https://lore.kernel.org/all/20250902104533.222730-1-lorenzo.stoakes@oracle.com/

Lorenzo Stoakes (2):
  mm: specify separate file and vm_file params in vm_area_desc
  mm: do not assume file == vma->vm_file in compat_vma_mmap_prepare()

 include/linux/fs.h               |  2 ++
 include/linux/mm_types.h         |  5 +--
 mm/internal.h                    |  4 +--
 mm/mmap.c                        |  2 +-
 mm/util.c                        | 52 ++++++++++++++++++++++++--------
 mm/vma.c                         |  5 +--
 mm/vma.h                         | 28 +++--------------
 tools/testing/vma/vma_internal.h | 36 +++++++++++++++-------
 8 files changed, 79 insertions(+), 55 deletions(-)

--
2.50.1

Powered by blists - more mailing lists