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: <CAHk-=wjeWqr+0Ktzbwqrw17aESe5dZm5Kt6nwqtKJX00VsDqWg@mail.gmail.com>
Date: Mon, 5 Aug 2024 17:13:34 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Nicholas Piggin <npiggin@...il.com>
Cc: Jeff Xu <jeffxu@...gle.com>, Michael Ellerman <mpe@...erman.id.au>, 
	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

On Mon, 5 Aug 2024 at 16:25, Nicholas Piggin <npiggin@...il.com> wrote:
>
> Can userspace on other archs not unmap their vdsos?

I think they can, and nobody cares. The "context.vdso" value stays at
some stale value, and anybody who tries to use it will just fail.

So what makes powerpc special is not "you can unmap the vdso", but
"powerpc cares".

I just don't quite know _why_ powerpc cares.

Judging by the comments and a quick 'grep', the reason may be

    arch/powerpc/perf/callchain_32.c

which seems to have some vdso knowledge.

But x86 does something kind of like that at signal frame generation
time, and doesn't care.

I really think it's an issue of "if you screw with the vdso, you get
to keep both broken pieces".

           Linus