From: Michael Ellerman <firstname.lastname@example.org> To: Paul Menzel <email@example.com>, Benjamin Herrenschmidt <firstname.lastname@example.org>, Paul Mackerras <email@example.com>, Christophe Leroy <firstname.lastname@example.org> Cc: Derek Parker <email@example.com>, Dmitrii Okunev <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, email@example.com Subject: Re: Possible regression by ab037dd87a2f (powerpc/vdso: Switch VDSO to generic C implementation.) Date: Thu, 29 Jul 2021 17:41:20 +1000 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <email@example.com> Paul Menzel <firstname.lastname@example.org> writes: > Dear Michael, > > > Am 28.07.21 um 14:43 schrieb Michael Ellerman: >> Paul Menzel <email@example.com> writes: >>> Am 28.07.21 um 01:14 schrieb Benjamin Herrenschmidt: >>>> On Tue, 2021-07-27 at 10:45 +0200, Paul Menzel wrote: >>> >>>>> On ppc64le Go 1.16.2 from Ubuntu 21.04 terminates with a segmentation >>>>> fault , and it might be related to *[release-branch.go1.16] runtime: >>>>> fix crash during VDSO calls on PowerPC* , conjecturing that commit >>>>> ab037dd87a2f (powerpc/vdso: Switch VDSO to generic C implementation.) >>>>> added in Linux 5.11 causes this. >>>>> >>>>> If this is indeed the case, this would be a regression in userspace. Is >>>>> there a generic fix or should the change be reverted? >>>> >>>> From the look at the links you posted, this appears to be completely >>>> broken assumptions by Go that some registers don't change while calling >>>> what essentially are external library functions *while inside those >>>> functions* (ie in this case from a signal handler). >>>> >>>> I suppose it would be possible to build the VDSO with gcc arguments to >>>> make it not use r30, but that's just gross... >>> >>> Thank you for looking into this. No idea, if it falls under Linux’ no >>> regression policy or not. >> >> Reluctantly yes, I think it does. Though it would have been good if it >> had been reported to us sooner. >> >> It looks like that Go fix is only committed to master, and neither of >> the latest Go 1.16 or 1.15 releases contain the fix? ie. there's no way >> for a user to get a working version of Go other than building master? > > I heard it is going to be in Go 1.16.7, but I do not know much about Go. > Maybe the folks in Cc can chime in. > >> I'll see if we can work around it in the kernel. Are you able to test a >> kernel patch if I send you one? > > Yes, I could test a Linux kernel patch on ppc64le (POWER 8) running > Ubuntu 21.04. Thanks, would be great if you can test on your setup. Patch below. I haven't been able to reproduce the crash by following the instructions in your bug report, I have go1.13.8, I guess the crash is only in newer versions? cheers diff --git a/arch/powerpc/kernel/vdso64/Makefile b/arch/powerpc/kernel/vdso64/Makefile index 2813e3f98db6..3c5baaa6f1e7 100644 --- a/arch/powerpc/kernel/vdso64/Makefile +++ b/arch/powerpc/kernel/vdso64/Makefile @@ -27,6 +27,13 @@ KASAN_SANITIZE := n ccflags-y := -shared -fno-common -fno-builtin -nostdlib \ -Wl,-soname=linux-vdso64.so.1 -Wl,--hash-style=both + +# Go prior to 1.16.x assumes r30 is not clobbered by any VDSO code. That used to be true +# by accident when the VDSO was hand-written asm code, but may not be now that the VDSO is +# compiler generated. To avoid breaking Go tell GCC not to use r30. Impact on code +# generation is minimal, it will just use r29 instead. +ccflags-y += $(call cc-option, -ffixed-r30) + asflags-y := -D__VDSO64__ -s targets += vdso64.lds
next prev parent reply other threads:[~2021-07-29 7:41 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-07-27 8:45 Paul Menzel 2021-07-27 23:14 ` Benjamin Herrenschmidt 2021-07-28 8:26 ` Paul Menzel 2021-07-28 12:43 ` Michael Ellerman 2021-07-28 12:53 ` Paul Menzel 2021-07-29 7:41 ` Michael Ellerman [this message] 2021-07-29 8:33 ` Paul Menzel 2021-07-29 12:58 ` Michael Ellerman [not found] ` <firstname.lastname@example.org> 2021-07-29 8:48 ` Andreas Schwab 2021-08-02 6:04 ` Michael Ellerman [not found] ` <OF44F7146F.67A4C1C2-ON00258720.004DBF64-00258720.004FCFCC@ibm.com> 2021-08-02 6:18 ` Michael Ellerman 2021-08-02 12:48 ` Benjamin Herrenschmidt 2021-08-02 18:07 ` Segher Boessenkool 2021-08-02 18:14 ` Lynn Boger
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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: Possible regression by ab037dd87a2f (powerpc/vdso: Switch VDSO to generic C implementation.)' \ /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
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.