[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKbZUD3B03Zjex4STW8J_1VJhpsYb=1mnZL2-vSaW-CaZdzLiA@mail.gmail.com>
Date: Mon, 5 Aug 2024 14:33:41 +0100
From: Pedro Falcato <pedro.falcato@...il.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: kernel test robot <oliver.sang@...el.com>, Jeff Xu <jeffxu@...omium.org>, oe-lkp@...ts.linux.dev,
lkp@...el.com, linux-kernel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>, Kees Cook <keescook@...omium.org>,
"Liam R. Howlett" <Liam.Howlett@...cle.com>, Dave Hansen <dave.hansen@...el.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Guenter Roeck <groeck@...omium.org>,
Jann Horn <jannh@...gle.com>, Jeff Xu <jeffxu@...gle.com>, Jonathan Corbet <corbet@....net>,
Jorge Lucangeli Obes <jorgelo@...omium.org>, Matthew Wilcox <willy@...radead.org>,
Muhammad Usama Anjum <usama.anjum@...labora.com>, Stephen Röttger <sroettger@...gle.com>,
Suren Baghdasaryan <surenb@...gle.com>, Amer Al Shanawany <amer.shanawany@...il.com>,
Javier Carrasco <javier.carrasco.cruz@...il.com>, Shuah Khan <shuah@...nel.org>,
linux-api@...r.kernel.org, linux-mm@...ck.org, ying.huang@...el.com,
feng.tang@...el.com, fengwei.yin@...el.com
Subject: Re: [linus:master] [mseal] 8be7258aad: stress-ng.pagemove.page_remaps_per_sec
-4.4% regression
On Sun, Aug 4, 2024 at 9:33 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> On Sun, 4 Aug 2024 at 01:59, kernel test robot <oliver.sang@...el.com> wrote:
> >
> > kernel test robot noticed a -4.4% regression of stress-ng.pagemove.page_remaps_per_sec on
> > commit 8be7258aad44 ("mseal: add mseal syscall")
>
> Ok, it's basically just the vma walk in can_modify_mm():
>
> > 1.06 +0.1 1.18 perf-profile.self.cycles-pp.mas_next_slot
> > 1.50 +0.5 1.97 perf-profile.self.cycles-pp.mas_find
> > 0.00 +1.4 1.35 perf-profile.self.cycles-pp.can_modify_mm
> > 3.13 +2.0 5.13 perf-profile.self.cycles-pp.mas_walk
>
> and looks like it's two different pathways. We have __do_sys_mremap ->
> mremap_to -> do_munmap -> do_vmi_munmap -> can_modify_mm for the
> destination mapping, but we also have mremap_to() calling
> can_modify_mm() directly for the source mapping.
>
> And then do_vmi_munmap() will do it's *own* vma_find() after having
> done arch_unmap().
>
> And do_munmap() will obviously do its own vma lookup as part of
> calling vma_to_resize().
>
> So it looks like a large portion of this regression is because the
> mseal addition just ends up walking the vma list way too much.
Can we rollback the upfront checks "funny business" and just call
can_modify_vma directly in relevant places? I still don't believe in
the partial mprotect/munmap "security risks" that were stated in the
mseal thread (and these operations can already fail for many other
reasons than mseal) :)
I don't mind taking a look myself, just want to make sure I'm not
stepping on anyone's toes here.
--
Pedro
Powered by blists - more mailing lists