From: Florian Weimer <fweimer@redhat.com>
To: Nicholas Piggin <npiggin@gmail.com>
Cc: linuxppc-dev@lists.ozlabs.org, Alan Modra <amodra@gmail.com>,
musl@lists.openwall.com, libc-alpha@sourceware.org
Subject: [musl] Re: [PATCH v2] powerpc/64/signal: balance return predictor stack in signal trampoline
Date: Fri, 22 Jan 2021 12:27:14 +0100 [thread overview]
Message-ID: <87im7pp5yl.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <20200511101952.1463138-1-npiggin@gmail.com> (Nicholas Piggin's message of "Mon, 11 May 2020 20:19:52 +1000")
* Nicholas Piggin:
> diff --git a/arch/powerpc/kernel/vdso64/sigtramp.S b/arch/powerpc/kernel/vdso64/sigtramp.S
> index a8cc0409d7d2..bbf68cd01088 100644
> --- a/arch/powerpc/kernel/vdso64/sigtramp.S
> +++ b/arch/powerpc/kernel/vdso64/sigtramp.S
> @@ -6,6 +6,7 @@
> * Copyright (C) 2004 Benjamin Herrenschmuidt (benh@kernel.crashing.org), IBM Corp.
> * Copyright (C) 2004 Alan Modra (amodra@au.ibm.com)), IBM Corp.
> */
> +#include <asm/cache.h> /* IFETCH_ALIGN_BYTES */
> #include <asm/processor.h>
> #include <asm/ppc_asm.h>
> #include <asm/unistd.h>
> @@ -14,21 +15,17 @@
>
> .text
>
> -/* The nop here is a hack. The dwarf2 unwind routines subtract 1 from
> - the return address to get an address in the middle of the presumed
> - call instruction. Since we don't have a call here, we artificially
> - extend the range covered by the unwind info by padding before the
> - real start. */
> - nop
> .balign 8
> + .balign IFETCH_ALIGN_BYTES
> V_FUNCTION_BEGIN(__kernel_sigtramp_rt64)
> -.Lsigrt_start = . - 4
> +.Lsigrt_start:
> + bctrl /* call the handler */
> addi r1, r1, __SIGNAL_FRAMESIZE
> li r0,__NR_rt_sigreturn
> sc
> .Lsigrt_end:
> V_FUNCTION_END(__kernel_sigtramp_rt64)
> -/* The ".balign 8" above and the following zeros mimic the old stack
> +/* The .balign 8 above and the following zeros mimic the old stack
> trampoline layout. The last magic value is the ucontext pointer,
> chosen in such a way that older libgcc unwind code returns a zero
> for a sigcontext pointer. */
As far as I understand it, this breaks cancellation handling on musl and
future glibc because it is necessary to look at the signal delivery
location to see if a system call sequence has result in an action, and
that location is no longer in user code after this change.
We have a glibc test in preparation of our change, and it started
failing:
Linux 5.10 breaks sigcontext_get_pc on powerpc64
<https://sourceware.org/bugzilla/show_bug.cgi?id=27223>
Isn't it possible to avoid the return predictor desynchronization by
adding the appropriate hint?
Thanks,
Florian
--
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
next parent reply other threads:[~2021-01-22 11:27 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200511101952.1463138-1-npiggin@gmail.com>
2021-01-22 11:27 ` Florian Weimer [this message]
2021-01-22 14:44 ` Rich Felker
2021-01-22 18:19 ` Raoni Fassina Firmino
2021-01-22 18:31 ` Rich Felker
2021-01-22 18:50 ` Raoni Fassina Firmino
2021-01-22 18:13 ` Raoni Fassina Firmino
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87im7pp5yl.fsf@oldenburg.str.redhat.com \
--to=fweimer@redhat.com \
--cc=amodra@gmail.com \
--cc=libc-alpha@sourceware.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=musl@lists.openwall.com \
--cc=npiggin@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).