Le 06/08/2024 à 04:01, Michael Ellerman a écrit :
Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes:
On Mon, 5 Aug 2024 at 16:25, Nicholas Piggin <npiggin@xxxxxxxxx> 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@xxxxxxxxxx/
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@xxxxxxxxxx/
But I think that series got a bit big and complicated and Dmitry had to
move on to other things.
cheers
