[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 2 Feb 2024 15:36:17 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: "Liam R. Howlett" <Liam.Howlett@...cle.com>, Linus Torvalds <torvalds@...ux-foundation.org>,
Jeff Xu <jeffxu@...omium.org>, Jeff Xu <jeffxu@...gle.com>,
Jonathan Corbet <corbet@....net>, akpm@...ux-foundation.org, keescook@...omium.org,
jannh@...gle.com, sroettger@...gle.com, willy@...radead.org,
gregkh@...uxfoundation.org, usama.anjum@...labora.com, rdunlap@...radead.org,
jorgelo@...omium.org, groeck@...omium.org, linux-kernel@...r.kernel.org,
linux-kselftest@...r.kernel.org, linux-mm@...ck.org, pedro.falcato@...il.com,
dave.hansen@...el.com, linux-hardening@...r.kernel.org
Subject: Re: [PATCH v8 0/4] Introduce mseal
On Fri, 2 Feb 2024 at 13:18, Liam R. Howlett <Liam.Howlett@...cle.com> wrote:
>
> There will be a larger performance cost to checking up front without
> allowing the partial completion.
I suspect that for mseal(), the only half-way common case will be
sealing an area that is entirely contained within one vma.
So the cost will be the vma splitting (if it's not the whole vma), and
very unlikely to be any kind of "walk the vma's to check that they can
all be sealed" loop up-front.
We'll see, but that's my gut feel, at least.
Linus
Powered by blists - more mailing lists