On Tue, May 13, 2025 at 11:01:41AM +0200, David Hildenbrand wrote:
> On 09.05.25 14:13, Lorenzo Stoakes wrote:
> > Provide a means by which drivers can specify which fields of those
> > permitted to be changed should be altered to prior to mmap()'ing a
> > range (which may either result from a merge or from mapping an entirely new
> > VMA).
> >
> > Doing so is substantially safer than the existing .mmap() calback which
> > provides unrestricted access to the part-constructed VMA and permits
> > drivers and file systems to do 'creative' things which makes it hard to
> > reason about the state of the VMA after the function returns.
> >
> > The existing .mmap() callback's freedom has caused a great deal of issues,
> > especially in error handling, as unwinding the mmap() state has proven to
> > be non-trivial and caused significant issues in the past, for instance
> > those addressed in commit 5de195060b2e ("mm: resolve faulty mmap_region()
> > error path behaviour").
> >
> > It also necessitates a second attempt at merge once the .mmap() callback
> > has completed, which has caused issues in the past, is awkward, adds
> > overhead and is difficult to reason about.
> >
> > The .mmap_prepare() callback eliminates this requirement, as we can update
> > fields prior to even attempting the first merge. It is safer, as we heavily
> > restrict what can actually be modified, and being invoked very early in the
> > mmap() process, error handling can be performed safely with very little
> > unwinding of state required.
> >
> > The .mmap_prepare() and deprecated .mmap() callbacks are mutually
> > exclusive, so we permit only one to be invoked at a time.
> >
> > Update vma userland test stubs to account for changes.
> >
> > Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx>
> > ---
> > include/linux/fs.h | 25 ++++++++++++
> > include/linux/mm_types.h | 24 +++++++++++
> > mm/memory.c | 3 +-
> > mm/mmap.c | 2 +-
> > mm/vma.c | 68 +++++++++++++++++++++++++++++++-
> > tools/testing/vma/vma_internal.h | 66 ++++++++++++++++++++++++++++---
> > 6 files changed, 180 insertions(+), 8 deletions(-)
> >
> > diff --git a/include/linux/fs.h b/include/linux/fs.h
> > index 016b0fe1536e..e2721a1ff13d 100644
> > --- a/include/linux/fs.h
> > +++ b/include/linux/fs.h
> > @@ -2169,6 +2169,7 @@ struct file_operations {
> > int (*uring_cmd)(struct io_uring_cmd *ioucmd, unsigned int issue_flags);
> > int (*uring_cmd_iopoll)(struct io_uring_cmd *, struct io_comp_batch *,
> > unsigned int poll_flags);
> > + int (*mmap_prepare)(struct vm_area_desc *);
> > } __randomize_layout;
> > /* Supports async buffered reads */
> > @@ -2238,11 +2239,35 @@ struct inode_operations {
> > struct offset_ctx *(*get_offset_ctx)(struct inode *inode);
> > } ____cacheline_aligned;
> > +/* Did the driver provide valid mmap hook configuration? */
> > +static inline bool file_has_valid_mmap_hooks(struct file *file)
> > +{
> > + bool has_mmap = file->f_op->mmap;
> > + bool has_mmap_prepare = file->f_op->mmap_prepare;
> > +
> > + /* Hooks are mutually exclusive. */
> > + if (WARN_ON_ONCE(has_mmap && has_mmap_prepare))
> > + return false;
> > + if (WARN_ON_ONCE(!has_mmap && !has_mmap_prepare))
> > + return false;
> > +
> > + return true;
> > +}
>
> So, if neither is set, it's also an invalid setting, understood.
>
> So we want XOR.
>
>
>
> const bool has_mmap = file->f_op->mmap;
> const bool has_mmap_prepare = file->f_op->mmap_prepare;
> const bool mutual_exclusive = has_mmap ^ has_mmap_prepare;
>
> WARN_ON_ONCE(!mutual_exclusive)
> return mutual_exclusive;
Yeah I did consider xor like this but I've always found it quite confusing
in this kind of context, honestly.
In a way I think it's a bit easier spelt out as it is now. But happy to
change if you feel strongly about it? :)
>
> --
> Cheers,
>
> David / dhildenb
>
Thanks!
