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 for Android: free password hash cracker in your pocket

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

Message-ID: <87bk25j1sx.fsf@mail.lhotse>
Date: Tue, 06 Aug 2024 22:03:42 +1000
From: Michael Ellerman <mpe@...erman.id.au>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Jeff Xu <jeffxu@...gle.com>, Nicholas Piggin <npiggin@...il.com>,
 Christophe Leroy <christophe.leroy@...roup.eu>, 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 19:14, Michael Ellerman <mpe@...erman.id.au> wrote:
>>
>> Needs a slight tweak to compile, vvar_close() needs to return void.
>
> Ack, shows just how untested it was.
>
>> And should probably be renamed vdso_close().
>
> .. and that was due to the initial confusion that I then fixed, but
> didn't fix the naming.

Ack.

> So yes, those fixes look ObviouslyCorrect(tm).

Needs another slight tweak to work correctly. Diff below.

With that our sigreturn_vdso selftest passes, and the CRIU vdso tests
pass also. So LGTM.

I'm not sure of the urgency on this, do you want to apply it directly?
If so feel free to add my tested-by/sob etc.

Or should I turn it into a series and post it?

cheers

diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index 431b46976db8..ed5ac4af4d83 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -85,6 +85,15 @@ static void vdso_close(const struct vm_special_mapping *sm,
                        struct vm_area_struct *vma)
 {
 	struct mm_struct *mm = vma->vm_mm;
+
+	/*
+	 * close() is called for munmap() but also for mremap(). In the mremap()
+	 * case the vdso pointer has already been updated by the mremap() hook
+	 * above, so it must not be set to NULL here. 
+	 */
+	if (vma->vm_start != (unsigned long)mm->context.vdso)
+		return;
+
 	mm->context.vdso = NULL;
 }