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 22:58:59 +1000 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <email@example.com> Paul Menzel <firstname.lastname@example.org> writes: > Am 29.07.21 um 09:41 schrieb Michael Ellerman: >> Paul Menzel <email@example.com> writes: > >>> Am 28.07.21 um 14:43 schrieb Michael Ellerman: >>>> Paul Menzel <firstname.lastname@example.org> 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). OK thanks. I can reproduce with that. >> 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. I made it 1.16.x because it wasn't 100% clear on whether the fix will land in 1.16.7 or not. For our purposes 1.16.x is good enough, we'll need to carry the workaround until 1.16 is well and truly EOL, so it doesn't really matter which point release it's in. >> +# 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 <email@example.com> Thanks. > (Probably the commit should be tagged for the stable series too.) Yep. cheers
next prev parent reply other threads:[~2021-07-29 12:59 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 2021-07-29 12:58 ` Michael Ellerman [this message] [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.