[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <06e2e29d-20c7-4999-b36b-343cf083f766@redhat.com>
Date: Tue, 13 May 2025 15:25:07 +0200
From: David Hildenbrand <david@...hat.com>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
"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, Alexander Viro <viro@...iv.linux.org.uk>,
Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>,
Matthew Wilcox <willy@...radead.org>
Subject: Re: [PATCH v2 1/3] mm: introduce new .mmap_prepare() file callback
On 13.05.25 11:32, Lorenzo Stoakes wrote:
> 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@...cle.com>
>>> ---
>>> 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.
With the local variable I think it's quite helpful (no need for a
comment :P ).
>
> 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? :)
Certainly not strongly! :)
--
Cheers,
David / dhildenb
Powered by blists - more mailing lists