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] [day] [month] [year] [list]

Message-ID: <fe46ee6f-24c2-42be-942c-e03bc2b6e0aa@csgroup.eu>
Date: Fri, 13 Sep 2024 07:47:17 +0200
From: Christophe Leroy <christophe.leroy@...roup.eu>
To: Michael Ellerman <mpe@...erman.id.au>,
 Linus Torvalds <torvalds@...ux-foundation.org>,
 Nicholas Piggin <npiggin@...il.com>
Cc: Jeff Xu <jeffxu@...gle.com>, 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

Le 06/08/2024 à 04:01, Michael Ellerman a écrit :
> Linus Torvalds <torvalds@...ux-foundation.org> writes:
>> 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.
> 
> AFAIK for CRIU the problem is signal delivery:
> 
> arch/powerpc/kernel/signal_64.c:
> 
> int handle_rt_signal64(struct ksignal *ksig, sigset_t *set,
> 		struct task_struct *tsk)
> {
>          ...
> 	/* Set up to return from userspace. */
> 	if (tsk->mm->context.vdso) {
> 		regs_set_return_ip(regs, VDSO64_SYMBOL(tsk->mm->context.vdso, sigtramp_rt64));
> 
> 
> ie. if the VDSO is moved but mm->context.vdso is not updated, signal
> delivery will crash in userspace.
> 
> x86-64 always uses SA_RESTORER, and arm64 & s390 can use SA_RESTORER, so
> I think CRIU uses that to avoid problems with signal delivery when the
> VDSO is moved.
> 
> riscv doesn't support SA_RESTORER but I guess CRIU doesn't support riscv
> yet so it's not become a problem.
> 
> There was a patch to support SA_RESTORER on powerpc, but I balked at
> merging it because I couldn't find anyone on the glibc side to say
> whether they wanted it or not. I guess I should have just merged it.

The patch is at 
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/afe50d1db63a10fde9547ea08fe1fa68b0638aba.1624618157.git.christophe.leroy@csgroup.eu/

It still applies cleanly.

Christophe

> 
> There was an attempt to unify all the vdso stuff and handle the
> VDSO mremap case in generic code:
> 
>    https://lore.kernel.org/lkml/20210611180242.711399-17-dima@arista.com/
> 
> But I think that series got a bit big and complicated and Dmitry had to
> move on to other things.
> 
> cheers