From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by sourceware.org (Postfix) with ESMTP id D28D0382D83C for ; Fri, 22 Jan 2021 11:27:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D28D0382D83C Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-560-K6C89M0PNcCw2SmyYe8Rrg-1; Fri, 22 Jan 2021 06:27:19 -0500 X-MC-Unique: K6C89M0PNcCw2SmyYe8Rrg-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 25D24180A096; Fri, 22 Jan 2021 11:27:18 +0000 (UTC) Received: from oldenburg.str.redhat.com (ovpn-113-35.ams2.redhat.com [10.36.113.35]) by smtp.corp.redhat.com (Postfix) with ESMTPS id AB33810023BF; Fri, 22 Jan 2021 11:27:16 +0000 (UTC) From: Florian Weimer To: Nicholas Piggin Cc: linuxppc-dev@lists.ozlabs.org, Alan Modra , musl@lists.openwall.com, libc-alpha@sourceware.org Subject: Re: [PATCH v2] powerpc/64/signal: balance return predictor stack in signal trampoline References: <20200511101952.1463138-1-npiggin@gmail.com> Date: Fri, 22 Jan 2021 12:27:14 +0100 In-Reply-To: <20200511101952.1463138-1-npiggin@gmail.com> (Nicholas Piggin's message of "Mon, 11 May 2020 20:19:52 +1000") Message-ID: <87im7pp5yl.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-12.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2021 11:27:25 -0000 * 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 /* IFETCH_ALIGN_BYTES */ > #include > #include > #include > @@ -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 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