[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f860d082-384d-4230-bb1c-09206c7daf72@redhat.com>
Date: Fri, 25 Jul 2025 20:10:11 +0200
From: David Hildenbrand <david@...hat.com>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
Jeff Xu <jeffxu@...omium.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
"Liam R . Howlett" <Liam.Howlett@...cle.com>,
Vlastimil Babka <vbabka@...e.cz>, Jann Horn <jannh@...gle.com>,
Pedro Falcato <pfalcato@...e.de>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, Kees Cook <kees@...nel.org>
Subject: Re: [PATCH v4 4/5] mm/mseal: simplify and rename VMA gap check
On 25.07.25 19:43, Lorenzo Stoakes wrote:
> On Fri, Jul 25, 2025 at 10:30:08AM -0700, Jeff Xu wrote:
>> Hi Lorenzo,
>>
>> On Fri, Jul 25, 2025 at 1:30 AM Lorenzo Stoakes
>> <lorenzo.stoakes@...cle.com> wrote:
>>>
>>> The check_mm_seal() function is doing something general - checking whether
>>> a range contains only VMAs (or rather that it does NOT contain any
>>> unmapped regions).
>>>
>>> So rename this function to range_contains_unmapped().
>>>
>> Thanks for keeping the comments.
>
> You're welcome.
>
>>
>> In the prior version of this patch, I requested that we keep the
>> check_mm_seal() and its comments. And this version keeps the comments
>> but removes the check_mm_seal() name.
>
> I didn't catch that being your request.
>
>>
>> As I said, check_mm_seal() with its comments is a contract for
>> entry-check for mseal(). My understanding is that you are going to
>> move range_contains_unmapped() to vma.c. When that happens, mseal()
>> will lose this entry-check contract.
>
> This is just bizarre.
>
> Code doesn't stop working if you put it in another function.
>
> And you're now reviewing me for stuff I haven't done? :P
>
>>
>> Contact is a great way to hide implementation details. Could you
>> please keep check_mm_seal() in mseal.c and create
>> range_contains_unmapped() in vma.c. Then you can refactor as needed.
>
> Wait what?
do_mseal() calls range_contains_unmapped(), so I don't see the problem.
We could add a comment above the range_contains_unmapped(), call stating
*why* we do that, which is much more relevant than some check_XXX function.
/*
* mseal() is documented to reject ranges that contain unmapped ranges
* (VMA holes): we can only seal VMAs, so nothing would stop mmap() etc.
* from succeeding on these unmapped ranged later, and we would not
* actually be sealing the requested range.
*/
Something like that.
--
Cheers,
David / dhildenb
Powered by blists - more mailing lists