linux-kernel - Re: [linus:master] [mseal] 8be7258aad: stress-ng.pagemove.page_remaps_per

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87o766iehy.fsf@mail.lhotse>
Date: Tue, 06 Aug 2024 12:14:49 +1000
From: Michael Ellerman <mpe@...erman.id.au>
To: Linus Torvalds <torvalds@...ux-foundation.org>, Jeff Xu
 <jeffxu@...gle.com>, Nicholas Piggin <npiggin@...il.com>, Christophe Leroy
 <christophe.leroy@...roup.eu>
Cc: Pedro Falcato <pedro.falcato@...il.com>, 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>, 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

Linus Torvalds <torvalds@...ux-foundation.org> writes:
> On Mon, 5 Aug 2024 at 11:55, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
>>
>> So please consider this a "maybe something like this" patch, but that
>> 'arch_unmap()' really is pretty nasty
>
> Actually, the whole powerpc vdso code confused me. It's not the vvar
> thing that wants this close thing, it's the other ones that have the
> remap thing.
>
> .. and there were two of those error cases that needed to reset the
> vdso pointer.
>
> That all shows just how carefully I was reading this code.
>
> New version - still untested, but now I've read through it one more
> time - attached.

Needs a slight tweak to compile, vvar_close() needs to return void. And
should probably be renamed vdso_close(). Diff below if anyone else wants
to test it.

I'm testing it now, but it should do what we need.

cheers

diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index 6fa041a6690a..431b46976db8 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -81,8 +81,8 @@ static int vdso64_mremap(const struct vm_special_mapping *sm, struct vm_area_str
 	return vdso_mremap(sm, new_vma, &vdso64_end - &vdso64_start);
 }

-static int vvar_close(const struct vm_special_mapping *sm,
-		      struct vm_area_struct *vma)
+static void vdso_close(const struct vm_special_mapping *sm,
+                       struct vm_area_struct *vma)
 {
 	struct mm_struct *mm = vma->vm_mm;
 	mm->context.vdso = NULL;
@@ -99,13 +99,13 @@ static struct vm_special_mapping vvar_spec __ro_after_init = {
 static struct vm_special_mapping vdso32_spec __ro_after_init = {
 	.name = "[vdso]",
 	.mremap = vdso32_mremap,
-	.close = vvar_close,
+	.close = vdso_close,
 };

 static struct vm_special_mapping vdso64_spec __ro_after_init = {
 	.name = "[vdso]",
 	.mremap = vdso64_mremap,
-	.close = vvar_close,
+	.close = vdso_close,
 };

 #ifdef CONFIG_TIME_NS