From: Paul Menzel <firstname.lastname@example.org> To: Michael Ellerman <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 10:33:17 +0200 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <email@example.com> Dear Michael, Am 29.07.21 um 09:41 schrieb Michael Ellerman: > Paul Menzel <firstname.lastname@example.org> writes: >> 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? I only used go version 1.16.2 packaged in Ubuntu 21.04 (1.16~0ubuntu1). > 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 Probably that needs to be 1.16.7. > +# 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 With this applied to Linux, go does not crash with a segmentation fault anymore. Tested-by: Paul Menzel <firstname.lastname@example.org> (Probably the commit should be tagged for the stable series too.) Kind regards, Paul
next prev parent reply other threads:[~2021-07-29 8:33 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 2021-07-29 8:33 ` Paul Menzel [this message] 2021-07-29 12:58 ` Michael Ellerman [not found] ` <email@example.com> 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 \ --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 \ --firstname.lastname@example.org \ --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.