runtime: fix crash during VDSO calls on arm #34030

nyuichi · 2019-09-03T04:45:01Z

As discussed in #32912, a crash occurs when go runtime calls a VDSO function (say
__vdso_clock_gettime) and a signal arrives to that thread.
Since VDSO functions temporarily destroy the G register (R10),
Go functions asynchronously executed in that thread (i.e. Go's signal
handler) can try to load data from the destroyed G, which causes
segmentation fault.

To fix the issue a guard is inserted in front of sigtrampgo, so that the control escapes from
signal handlers without touching G in case the signal occurred in the VDSO context.
The test case included in the patch is take from discussion in a relevant thread on github:
#32912 (comment).
This patch not only fixes the issue on AArch64 but also that on 32bit ARM.

Fixes #32912

googlebot · 2019-09-03T04:45:05Z

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it!) and we'll verify it.

What to do if you already signed the CLA

Individual signers

It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

nyuichi · 2019-09-03T04:50:34Z

@googlebot I signed it!

googlebot · 2019-09-03T04:50:37Z

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

gopherbot · 2019-09-03T04:56:56Z

This PR (HEAD: 6ccc156) has been imported to Gerrit for code review.

Please visit https://go-review.googlesource.com/c/go/+/192937 to see it.

Tip: You can toggle comments from me using the comments slash command (e.g. /comments off)
See the Wiki page for more info

gopherbot · 2019-09-03T04:58:45Z

Message from Gobot Gobot:

Patch Set 1:

Congratulations on opening your first change. Thank you for your contribution!

Next steps:
Within the next week or so, a maintainer will review your change and provide
feedback. See https://golang.org/doc/contribute.html#review for more info and
tips to get your patch through code review.

Most changes in the Go project go through a few rounds of revision. This can be
surprising to people new to the project. The careful, iterative review process
is our way of helping mentor contributors and ensuring that their contributions
have a lasting impact.

During May-July and Nov-Jan the Go project is in a code freeze, during which
little code gets reviewed or merged. If a reviewer responds with a comment like
R=go1.11, it means that this CL will be reviewed as part of the next development
cycle. See https://golang.org/s/release for more details.

Please don’t reply on this GitHub thread. Visit golang.org/cl/192937.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2019-09-03T12:58:09Z

Message from Ian Lance Taylor:

Patch Set 1:

Do you have a test case that you can add? A change like this should really have a test case.

I think that a better fix, that should work for all targets, would be to have sigtrampgo call inVDSOPage. I haven't implemented that because I wasn't able to find a test case that would fail on the builders, perhaps due to #33574.

Please don’t reply on this GitHub thread. Visit golang.org/cl/192937.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2019-09-03T13:12:14Z

Message from Yuichi Nishiwaki:

Patch Set 1:

Patch Set 1:

Do you have a test case that you can add? A change like this should really have a test case.

I only have the test case you made. I will add it later.

I think that a better fix, that should work for all targets, would be to have sigtrampgo call inVDSOPage. I haven't implemented that because I wasn't able to find a test case that would fail on the builders, perhaps due to #33574.

Can we really enter go functions without setting up the G register?
This is actually the point I was unsure and tried to avoid.

Please don’t reply on this GitHub thread. Visit golang.org/cl/192937.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2019-09-03T13:37:01Z

Message from Ian Lance Taylor:

Patch Set 1:

I think that a better fix, that should work for all targets, would be to have sigtrampgo call inVDSOPage. I haven't implemented that because I wasn't able to find a test case that would fail on the builders, perhaps due to #33574.

Can we really enter go functions without setting up the G register?
This is actually the point I was unsure and tried to avoid.

We can if the functions are marked //go:nosplit and if the function does not produce any write barriers. The latter will be enforced because sigtrampgo is marked //go:nowritebarrierrec. It might be necessary to change inVDSOPage to use for i := range vdsoSymbolKeys { k := &vdsoSymbolKeys[i] to avoid generating a write barrier by copying a vdsoSymbolKey value.

Please don’t reply on this GitHub thread. Visit golang.org/cl/192937.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2019-09-03T14:23:35Z

Message from Yuichi Nishiwaki:

Patch Set 1:

Patch Set 1:

I think that a better fix, that should work for all targets, would be to have sigtrampgo call inVDSOPage. I haven't implemented that because I wasn't able to find a test case that would fail on the builders, perhaps due to #33574.

Can we really enter go functions without setting up the G register?
This is actually the point I was unsure and tried to avoid.

We can if the functions are marked //go:nosplit and if the function does not produce any write barriers. The latter will be enforced because sigtrampgo is marked //go:nowritebarrierrec. It might be necessary to change inVDSOPage to use for i := range vdsoSymbolKeys { k := &vdsoSymbolKeys[i] to avoid generating a write barrier by copying a vdsoSymbolKey value.

Fair enough.
Do you have any idea on where to store G before going into VDSO functions?
In my patch it was TPIDRURW.

Please don’t reply on this GitHub thread. Visit golang.org/cl/192937.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2019-09-03T14:48:27Z

Message from Ian Lance Taylor:

Patch Set 1:

Do you have any idea on where to store G before going into VDSO functions?

Why do we have to?

Please don’t reply on this GitHub thread. Visit golang.org/cl/192937.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2019-09-03T15:28:34Z

Message from Yuichi Nishiwaki:

Patch Set 1:

Patch Set 1:

Do you have any idea on where to store G before going into VDSO functions?

Why do we have to?

I thought you meant that we would insert a branch in front of the body of sigtrampgo that conditionally restores the value of G.
Could you clarify what you do plan to do after checking inVDSOPage?

Please don’t reply on this GitHub thread. Visit golang.org/cl/192937.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2019-09-03T17:47:34Z

Message from Ian Lance Taylor:

Patch Set 1:

Do you have any idea on where to store G before going into VDSO functions?

Why do we have to?

I thought you meant that we would insert a branch in front of the body of sigtrampgo that conditionally restores the value of G.
Could you clarify what you do plan to do after checking inVDSOPage?

If we could store the G value before entering a VDSO function in such a way that the signal handler can retrieve it, that would be nice. But I don't see how to do that in general.

So what I'm suggesting is that if we are in the VDSO page on a GOARCH that stores the g value in a register, that we adjust the code to not require the g value. Any code that looks at will need a g == nil variant. I think this should be doable.

Please don’t reply on this GitHub thread. Visit golang.org/cl/192937.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2019-09-05T05:55:14Z

This PR (HEAD: 3a273a9) has been imported to Gerrit for code review.

Please visit https://go-review.googlesource.com/c/go/+/192937 to see it.

Tip: You can toggle comments from me using the comments slash command (e.g. /comments off)
See the Wiki page for more info

gopherbot · 2019-09-05T06:02:14Z

Message from Yuichi Nishiwaki:

Patch Set 2:

Patch Set 1:

Do you have any idea on where to store G before going into VDSO functions?

Why do we have to?

I thought you meant that we would insert a branch in front of the body of sigtrampgo that conditionally restores the value of G.
Could you clarify what you do plan to do after checking inVDSOPage?

If we could store the G value before entering a VDSO function in such a way that the signal handler can retrieve it, that would be nice. But I don't see how to do that in general.

So what I'm suggesting is that if we are in the VDSO page on a GOARCH that stores the g value in a register, that we adjust the code to not require the g value. Any code that looks at will need a g == nil variant. I think this should be doable.

I roughly reimplemented the patch following your suggestion, and added a test case.
However make.bash then started emitting a bunch of errors saying runtime: unexpected return pc for runtime.sigtramp.
Do you have any ideas how to fix this?

$ ./make.bash
Building Go cmd/dist using /usr/lib/go-1.11.
Building Go toolchain1 using /usr/lib/go-1.11.
Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1.
Building Go toolchain2 using go_bootstrap and Go toolchain1.
runtime: newstack at runtime.inVDSOPage+0xcc sp=0x2009c24 stack=[0x21ae000, 0x21b0000]
        morebuf={pc:0x53074 sp:0x2009c24 lr:0x0}
        sched={pc:0x64254 sp:0x2009c24 lr:0x53074 ctxt:0x0}
runtime.sigtrampgo(0x11, 0x2009c88, 0x2009d08)
        /home/pi/go/src/runtime/signal_unix.go:293 +0x3c fp=0x2009c78 sp=0x2009c24 pc=0x53074
runtime: unexpected return pc for runtime.sigtramp called from 0x7ed1c788
stack: frame={sp:0x2009c78, fp:0x2009c88} stack=[0x21ae000,0x21b0000)

runtime: newstack at runtime.inVDSOPage+0xcc sp=0x2055c24 stack=[0x21b2000, 0x21b4000]
        morebuf={pc:0x53074 sp:0x2055c24 lr:0x0}
        sched={pc:0x64254 sp:0x2055c24 lr:0x53074 ctxt:0x0}
runtime.sigtrampgo(0x11, 0x2055c88, 0x2055d08)
        /home/pi/go/src/runtime/signal_unix.go:293 +0x3c fp=0x2055c78 sp=0x2055c24 pc=0x53074
runtime: unexpected return pc for runtime.sigtramp called from 0x7ed1c788
stack: frame={sp:0x2055c78, fp:0x2055c88} stack=[0x21b2000,0x21b4000)

runtime.sigtramp(0x0, 0x1, 0x1e7c, 0x3e8, 0x0, 0x0, 0x1, 0x0, 0x0, 0x0, ...)
        /home/pi/go/src/runtime/sys_linux_arm.s:449 +0x28 fp=0x2055c88 sp=0x2055c78 pc=0x6af74
created by cmd/go/internal/work.(*Builder).Do
        /home/pi/go/src/cmd/go/internal/work/exec.go:164 +0x314
fatal error: runtime: stack split at bad time
runtime.sigtramp(0x0, 0x1, 0x1e7f, 0x3e8, 0x0, 0x1, 0x0, 0x0, 0x0, 0x0, ...)
        /home/pi/go/src/runtime/sys_linux_arm.s:449 +0x28 fp=0x2009c88 sp=0x2009c78 pc=0x6af74
created by cmd/go/internal/work.(*Builder).Do
        /home/pi/go/src/cmd/go/internal/work/exec.go:164 +0x314
fatal error: runtime: stack split at bad time

runtime stack:
runtime.throw(0x38b338, 0x20)
        /home/pi/go/src/runtime/panic.go:774 +0x5c fp=0x203bf20 sp=0x203bf0c pc=0x3df88
runtime.newstack()
        /home/pi/go/src/runtime/stack.go:957 +0x9cc fp=0x203bfe8 sp=0x203bf20 pc=0x57204
runtime.morestack()
        /home/pi/go/src/runtime/asm_arm.s:420 +0x60 fp=0x203bfec sp=0x203bfe8 pc=0x683cc

goroutine 965 [syscall]:
runtime.sigtrampgo(0x11, 0x2055c88, 0x2055d08)
        /home/pi/go/src/runtime/signal_unix.go:293 +0x3c fp=0x2055c78 sp=0x2055c24 pc=0x53074
runtime: unexpected return pc for runtime.sigtramp called from 0x7ed1c788
stack: frame={sp:0x2055c78, fp:0x2055c88} stack=[0x21b2000,0x21b4000)

runtime.sigtramp(0x0, 0x1, 0x1e7c, 0x3e8, 0x0, 0x0, 0x1, 0x0, 0x0, 0x0, ...)
        /home/pi/go/src/runtime/sys_linux_arm.s:449 +0x28 fp=0x2055c88 sp=0x2055c78 pc=0x6af74
created by cmd/go/internal/work.(*Builder).Do
        /home/pi/go/src/cmd/go/internal/work/exec.go:164 +0x314

goroutine 1 [semacquire]:
runtime.gopark(0x3b7408, 0x60efb0, 0x23c1912, 0x4)
        /home/pi/go/src/runtime/proc.go:304 +0xdc fp=0x216bd04 sp=0x216bcf0 pc=0x40358
runtime.goparkunlock(...)
        /home/pi/go/src/runtime/proc.go:310
runtime.semacquire1(0x250c978, 0x76f78300, 0x1, 0x0)
        /home/pi/go/src/runtime/sema.go:144 +0x1fc fp=0x216bd30 sp=0x216bd04 pc=0x50508
sync.runtime_Semacquire(0x250c978)
        /home/pi/go/src/runtime/sema.go:56 +0x34 fp=0x216bd44 sp=0x216bd30 pc=0x50160
sync.(*WaitGroup).Wait(0x250c970)
        /home/pi/go/src/sync/waitgroup.go:130 +0x84 fp=0x216bd68 sp=0x216bd44 pc=0x82eac
cmd/go/internal/work.(*Builder).Do(0x2280780, 0x21758c0)
        /home/pi/go/src/cmd/go/internal/work/exec.go:186 +0x334 fp=0x216bde8 sp=0x216bd68 pc=0x246cac
cmd/go/internal/work.InstallPackages(0x2088028, 0x4, 0x5, 0x2303a70, 0x4, 0x4)
        /home/pi/go/src/cmd/go/internal/work/build.go:572 +0xadc fp=0x216beac sp=0x216bde8 pc=0x241cc4
cmd/go/internal/work.runInstall(0x607d40, 0x2088028, 0x4, 0x5)
        /home/pi/go/src/cmd/go/internal/work/build.go:483 +0x4c fp=0x216bec8 sp=0x216beac pc=0x2410b4
main.main()
        /home/pi/go/src/cmd/go/main.go:189 +0x720 fp=0x216bfa4 sp=0x216bec8 pc=0x2f5aa0
runtime.main()
        /home/pi/go/src/runtime/proc.go:203 +0x208 fp=0x216bfe4 sp=0x216bfa4 pc=0x3fefc
runtime.goexit()
        /home/pi/go/src/runtime/asm_arm.s:864 +0x4 fp=0x216bfe4 sp=0x216bfe4 pc=0x6a008

goroutine 2 [force gc (idle)]:
runtime.gopark(0x3b7408, 0x60b5a0, 0x1411, 0x1)
        /home/pi/go/src/runtime/proc.go:304 +0xdc fp=0x202cfd8 sp=0x202cfc4 pc=0x40358
runtime.goparkunlock(...)
        /home/pi/go/src/runtime/proc.go:310
runtime.forcegchelper()
        /home/pi/go/src/runtime/proc.go:253 +0xb4 fp=0x202cfec sp=0x202cfd8 pc=0x401ec
runtime.goexit()
        /home/pi/go/src/runtime/asm_arm.s:864 +0x4 fp=0x202cfec sp=0x202cfec pc=0x6a008
created by runtime.init.4
        /home/pi/go/src/runtime/proc.go:242 +0x24

goroutine 3 [GC sweep wait]:
runtime.gopark(0x3b7408, 0x60b780, 0x140c, 0x1)
        /home/pi/go/src/runtime/proc.go:304 +0xdc fp=0x202d7d0 sp=0x202d7bc pc=0x40358
runtime.goparkunlock(...)
        /home/pi/go/src/runtime/proc.go:310
runtime.bgsweep(0x201e040)
        /home/pi/go/src/runtime/mgcsweep.go:89 +0x144 fp=0x202d7e4 sp=0x202d7d0 pc=0x3236c
runtime.goexit()
        /home/pi/go/src/runtime/asm_arm.s:864 +0x4 fp=0x202d7e4 sp=0x202d7e4 pc=0x6a008
created by runtime.gcenable
        /home/pi/go/src/runtime/mgc.go:210 +0x40

goroutine 4 [sleep]:
runtime.gopark(0x3b7408, 0x60b768, 0x3b1313, 0x2)
        /home/pi/go/src/runtime/proc.go:304 +0xdc fp=0x202df5c sp=0x202df48 pc=0x40358
runtime.goparkunlock(...)
        /home/pi/go/src/runtime/proc.go:310
runtime.scavengeSleep(0x5, 0x61a800, 0x0, 0x1)
        /home/pi/go/src/runtime/mgcscavenge.go:232 +0xcc fp=0x202df78 sp=0x202df5c pc=0x31758
runtime.bgscavenge(0x201e040)
        /home/pi/go/src/runtime/mgcscavenge.go:346 +0x3c0 fp=0x202dfe4 sp=0x202df78 pc=0x31b90
runtime.goexit()
        /home/pi/go/src/runtime/asm_arm.s:864 +0x4 fp=0x202dfe4 sp=0x202dfe4 pc=0x6a008
created by runtime.gcenable
        /home/pi/go/src/runtime/mgc.go:211 +0x5c

goroutine 17 [finalizer wait]:
runtime.gopark(0x3b7408, 0x61b414, 0x1410, 0x1)
        /home/pi/go/src/runtime/proc.go:304 +0xdc fp=0x20287a0 sp=0x202878c pc=0x40358
runtime.goparkunlock(...)
        /home/pi/go/src/runtime/proc.go:310
runtime.runfinq()
        /home/pi/go/src/runtime/mfinal.go:175 +0x9c fp=0x20287ec sp=0x20287a0 pc=0x2685c
runtime.goexit()
        /home/pi/go/src/runtime/asm_arm.s:864 +0x4 fp=0x20287ec sp=0x20287ec pc=0x6a008
created by runtime.createfing
        /home/pi/go/src/runtime/mfinal.go:156 +0x44runtime: newstack at runtime.inVDSOPage+0xcc sp=0x20fdc24 stack=[0x2562000, 0x2564000]
        morebuf={pc:0x53074 sp:0x20fdc24 lr:0x0}
        sched={pc:0x64254 sp:0x20fdc24 lr:0x53074 ctxt:0x0}

runtime.sigtrampgo(0x11, 0x20fdc88, 0x20fdd08)
        /home/pi/go/src/runtime/signal_unix.go:293 +0x3c fp=0x20fdc78 sp=0x20fdc24 pc=0x53074
runtime: unexpected return pc for runtime.sigtramp called from 0x7ed1c788
stack: frame={sp:0x20fdc78, fp:0x20fdc88} stack=[0x2562000,0x2564000)

runtime.sigtramp(0x0, 0x1, 0x1e7d, 0x3e8, 0x0, 0x1, 0x0, 0x0, 0x0, 0x0, ...)
        /home/pi/go/src/runtime/sys_linux_arm.s:449 +0x28 fp=0x20fdc88 sp=0x20fdc78 pc=0x6af74
created by cmd/go/internal/work.(*Builder).Do
        /home/pi/go/src/cmd/go/internal/work/exec.go:164 +0x314

fatal error: runtime: stack split at bad time
goroutine 18 [syscall]:
runtime.notetsleepg(0x61b6a0, 0xffffffff, 0xffffffff, 0x1)
        /home/pi/go/src/runtime/lock_futex.go:227 +0x24 fp=0x202c7c8 sp=0x202c7b0 pc=0x19df8
os/signal.signal_recv(0x0)
        /home/pi/go/src/runtime/sigqueue.go:147 +0x130 fp=0x202c7e0 sp=0x202c7c8 pc=0x545fc
os/signal.loop()
        /home/pi/go/src/os/signal/signal_unix.go:23 +0x14 fp=0x202c7ec sp=0x202c7e0 pc=0x179ef0
runtime.goexit()
        /home/pi/go/src/runtime/asm_arm.s:864 +0x4 fp=0x202c7ec sp=0x202c7ec pc=0x6a008
created by os/signal.init.0
        /home/pi/go/src/os/signal/signal_unix.go:29 +0x30

goroutine 949 [runnable]:
runtime.gopark(0x3b73f0, 0x66cfcfdc, 0x1b02, 0x5)
        /home/pi/go/src/runtime/proc.go:304 +0xdc fp=0x254865c sp=0x2548648 pc=0x40358
runtime.netpollblock(0x66cfcfc4, 0x72, 0x219c000, 0x200)
        /home/pi/go/src/runtime/netpoll.go:397 +0xb4 fp=0x2548674 sp=0x254865c pc=0x3ac74
internal/poll.runtime_pollWait(0x66cfcfc4, 0x72, 0xffffffff)
        /home/pi/go/src/runtime/netpoll.go:184 +0x44 fp=0x2548688 sp=0x2548674 pc=0x39edc
internal/poll.(*pollDesc).wait(0x2420094, 0x72, 0x201, 0x200, 0xffffffff)
        /home/pi/go/src/internal/poll/fd_poll_runtime.go:87 +0x30 fp=0x254869c sp=0x2548688 pc=0xc2494
internal/poll.(*pollDesc).waitRead(...)
        /home/pi/go/src/internal/poll/fd_poll_runtime.go:92
internal/poll.(*FD).Read(0x2420080, 0x219c000, 0x200, 0x200, 0x0, 0x0, 0x0)
        /home/pi/go/src/internal/poll/fd_unix.go:169 +0x178 fp=0x25486e4 sp=0x254869c pc=0xc333c
os.(*File).read(...)
        /home/pi/go/src/os/file_unix.go:259
os.(*File).Read(0x200e2a0, 0x219c000, 0x200, 0x200, 0x66d061e0, 0x14e74, 0x206a1f0)
        /home/pi/go/src/os/file.go:116 +0x5c fp=0x2548718 sp=0x25486e4 pc=0xc9660
bytes.(*Buffer).ReadFrom(0x2418280, 0x421e18, 0x200e2a0, 0x66d061e0, 0x2418280, 0x206a101, 0x0)
        /home/pi/go/src/bytes/buffer.go:204 +0xa4 fp=0x2548754 sp=0x2548718 pc=0xf1d28
io.copyBuffer(0x421908, 0x2418280, 0x421e18, 0x200e2a0, 0x0, 0x0, 0x0, 0x1, 0x2216ea0, 0x6a00c, ...)
        /home/pi/go/src/io/io.go:388 +0x2f8 fp=0x2548794 sp=0x2548754 pc=0xa4564
io.Copy(...)
        /home/pi/go/src/io/io.go:364
os/exec.(*Cmd).writerDescriptor.func1(0x0, 0x23fa1a0)
        /home/pi/go/src/os/exec/exec.go:311 +0x50 fp=0x25487d0 sp=0x2548794 pc=0xffa54
os/exec.(*Cmd).Start.func1(0x217e000, 0x2540040)
        /home/pi/go/src/os/exec/exec.go:435 +0x1c fp=0x25487e4 sp=0x25487d0 pc=0xffac4
runtime.goexit()
        /home/pi/go/src/runtime/asm_arm.s:864 +0x4 fp=0x25487e4 sp=0x25487e4 pc=0x6a008
created by os/exec.(*Cmd).Start
        /home/pi/go/src/os/exec/exec.go:434 +0x46c

goroutine 964 [runnable]:
syscall.Syscall(0x6, 0x3, 0x0, 0x0, 0x0, 0x0, 0x0)
        /home/pi/go/src/syscall/asm_linux_arm.s:14 +0x8 fp=0x255f608 sp=0x255f604 pc=0xadfe0
syscall.Close(0x3, 0x1, 0x0)
        /home/pi/go/src/syscall/zsyscall_linux_arm.go:310 +0x30 fp=0x255f628 sp=0x255f608 pc=0xabc2c
internal/poll.(*FD).destroy(0x23c6ec0, 0x2276001, 0x189950)
        /home/pi/go/src/internal/poll/fd_unix.go:78 +0x38 fp=0x255f640 sp=0x255f628 pc=0xc2dec
internal/poll.(*FD).decref(0x23c6ec0, 0x206c001, 0x8001)
        /home/pi/go/src/internal/poll/fd_mutex.go:213 +0x38 fp=0x255f650 sp=0x255f640 pc=0xc20e8
internal/poll.(*FD).Close(0x23c6ec0, 0x1c0, 0x421cf8)
        /home/pi/go/src/internal/poll/fd_unix.go:100 +0x44 fp=0x255f668 sp=0x255f650 pc=0xc2e9c
os.(*file).close(0x23c6ec0, 0x20a4070, 0x421e18)
        /home/pi/go/src/os/file_unix.go:244 +0x24 fp=0x255f68c sp=0x255f668 pc=0xcc9e0
os.(*File).Close(...)
        /home/pi/go/src/os/file_unix.go:233
cmd/go/internal/cache.FileHash(0x24544b0, 0x24, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
        /home/pi/go/src/cmd/go/internal/cache/hash.go:150 +0x4e8 fp=0x255f730 sp=0x255f68c pc=0x189bcc
cmd/go/internal/work.(*Builder).fileHash(0x2280780, 0x24544b0, 0x24, 0x24544b0, 0x24)
        /home/pi/go/src/cmd/go/internal/work/buildid.go:399 +0x24 fp=0x255f784 sp=0x255f730 pc=0x2447ec
cmd/go/internal/work.(*Builder).buildActionID(0x2280780, 0x21c7760, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
        /home/pi/go/src/cmd/go/internal/work/exec.go:316 +0x704 fp=0x255f9bc sp=0x255f784 pc=0x24747c
cmd/go/internal/work.(*Builder).build(0x2280780, 0x21c7760, 0x0, 0x0)
        /home/pi/go/src/cmd/go/internal/work/exec.go:397 +0x3ebc fp=0x255fef0 sp=0x255f9bc pc=0x24cf18
cmd/go/internal/work.(*Builder).Do.func2(0x21c7760)
        /home/pi/go/src/cmd/go/internal/work/exec.go:117 +0x64 fp=0x255ff64 sp=0x255fef0 pc=0x274784
cmd/go/internal/work.(*Builder).Do.func3(0x250c970, 0x2280780, 0x211ca50)
        /home/pi/go/src/cmd/go/internal/work/exec.go:177 +0x64 fp=0x255ffdc sp=0x255ff64 pc=0x274adc
runtime.goexit()
        /home/pi/go/src/runtime/asm_arm.s:864 +0x4 fp=0x255ffdc sp=0x255ffdc pc=0x6a008
created by cmd/go/internal/work.(*Builder).Do
        /home/pi/go/src/cmd/go/internal/work/exec.go:164 +0x314

goroutine 53 [GC worker (idle)]:
runtime.gopark(0x3b7364, 0x23a2c58, 0xffff1418, 0x0)
        /home/pi/go/src/runtime/proc.go:304 +0xdc fp=0x2029798 sp=0x2029784 pc=0x40358
runtime.gcBgMarkWorker(0x2022000)
        /home/pi/go/src/runtime/mgc.go:1846 +0xd8 fp=0x20297e4 sp=0x2029798 pc=0x2b05c
runtime.goexit()
        /home/pi/go/src/runtime/asm_arm.s:864 +0x4 fp=0x20297e4 sp=0x20297e4 pc=0x6a008
created by runtime.gcBgMarkStartWorkers
        /home/pi/go/src/runtime/mgc.go:1794 +0x68

goroutine 67 [GC worker (idle)]:
runtime.gopark(0x3b7364, 0x23e6990, 0xffff1418, 0x0)
        /home/pi/go/src/runtime/proc.go:304 +0xdc fp=0x202a798 sp=0x202a784 pc=0x40358
runtime.gcBgMarkWorker(0x2023300)
        /home/pi/go/src/runtime/mgc.go:1846 +0xd8 fp=0x202a7e4 sp=0x202a798 pc=0x2b05c
runtime.goexit()
        /home/pi/go/src/runtime/asm_arm.s:864 +0x4 fp=0x202a7e4 sp=0x202a7e4 pc=0x6a008
created by runtime.gcBgMarkStartWorkers
        /home/pi/go/src/runtime/mgc.go:1794 +0x68

goroutine 69 [GC worker (idle)]:
runtime.gopark(0x3b7364, 0x23e69a0, 0xffff1418, 0x0)
        /home/pi/go/src/runtime/proc.go:304 +0xdc fp=0x202ef98 sp=0x202ef84 pc=0x40358
runtime.gcBgMarkWorker(0x2025900)
        /home/pi/go/src/runtime/mgc.go:1846 +0xd8 fp=0x202efe4 sp=0x202ef98 pc=0x2b05c
runtime.goexit()
        /home/pi/go/src/runtime/asm_arm.s:864 +0x4 fp=0x202efe4 sp=0x202efe4 pc=0x6a008
created by runtime.gcBgMarkStartWorkers
        /home/pi/go/src/runtime/mgc.go:1794 +0x68

goroutine 950 [IO wait]:
runtime.gopark(0x3b73f0, 0x66cfcd48, 0x1b02, 0x5)
        /home/pi/go/src/runtime/proc.go:304 +0xdc fp=0x202f65c sp=0x202f648 pc=0x40358
runtime.netpollblock(0x66cfcd30, 0x72, 0x2407e00, 0x200)
        /home/pi/go/src/runtime/netpoll.go:397 +0xb4 fp=0x202f674 sp=0x202f65c pc=0x3ac74
internal/poll.runtime_pollWait(0x66cfcd30, 0x72, 0xffffffff)
        /home/pi/go/src/runtime/netpoll.go:184 +0x44 fp=0x202f688 sp=0x202f674 pc=0x39edc
internal/poll.(*pollDesc).wait(0x2420114, 0x72, 0x201, 0x200, 0xffffffff)
        /home/pi/go/src/internal/poll/fd_poll_runtime.go:87 +0x30 fp=0x202f69c sp=0x202f688 pc=0xc2494
internal/poll.(*pollDesc).waitRead(...)
        /home/pi/go/src/internal/poll/fd_poll_runtime.go:92
internal/poll.(*FD).Read(0x2420100, 0x2407e00, 0x200, 0x200, 0x0, 0x0, 0x0)
        /home/pi/go/src/internal/poll/fd_unix.go:169 +0x178 fp=0x202f6e4 sp=0x202f69c pc=0xc333c
os.(*File).read(...)
        /home/pi/go/src/os/file_unix.go:259
os.(*File).Read(0x200e2e0, 0x2407e00, 0x200, 0x200, 0x66d061e0, 0x3, 0x21758c0)
        /home/pi/go/src/os/file.go:116 +0x5c fp=0x202f718 sp=0x202f6e4 pc=0xc9660
bytes.(*Buffer).ReadFrom(0x24182a0, 0x421e18, 0x200e2e0, 0x66d061e0, 0x24182a0, 0x2280701, 0x35b230)
        /home/pi/go/src/bytes/buffer.go:204 +0xa4 fp=0x202f754 sp=0x202f718 pc=0xf1d28
io.copyBuffer(0x421908, 0x24182a0, 0x421e18, 0x200e2e0, 0x0, 0x0, 0x0, 0x1, 0x0, 0x0, ...)
        /home/pi/go/src/io/io.go:388 +0x2f8 fp=0x202f794 sp=0x202f754 pc=0xa4564
io.Copy(...)
        /home/pi/go/src/io/io.go:364
os/exec.(*Cmd).writerDescriptor.func1(0x0, 0x0)
        /home/pi/go/src/os/exec/exec.go:311 +0x50 fp=0x202f7d0 sp=0x202f794 pc=0xffa54
os/exec.(*Cmd).Start.func1(0x217e000, 0x2540070)
        /home/pi/go/src/os/exec/exec.go:435 +0x1c fp=0x202f7e4 sp=0x202f7d0 pc=0xffac4
runtime.goexit()
        /home/pi/go/src/runtime/asm_arm.s:864 +0x4 fp=0x202f7e4 sp=0x202f7e4 pc=0x6a008
created by os/exec.(*Cmd).Start
        /home/pi/go/src/os/exec/exec.go:434 +0x46c

goroutine 116 [timer goroutine (idle)]:
runtime.gopark(0x3b7408, 0x60ddf0, 0x1415, 0x1)
        /home/pi/go/src/runtime/proc.go:304 +0xdc fp=0x219b790 sp=0x219b77c pc=0x40358
runtime.goparkunlock(...)
        /home/pi/go/src/runtime/proc.go:310
runtime.timerproc(0x60ddf0)
        /home/pi/go/src/runtime/time.go:300 +0x364 fp=0x219b7e4 sp=0x219b790 pc=0x5bdb8
runtime.goexit()
        /home/pi/go/src/runtime/asm_arm.s:864 +0x4 fp=0x219b7e4 sp=0x219b7e4 pc=0x6a008
created by runtime.(*timersBucket).addtimerLocked
        /home/pi/go/src/runtime/time.go:166 +0x174

goroutine 148 [GC worker (idle)]:
runtime.gopark(0x3b7364, 0x2014800, 0xffff1418, 0x0)
        /home/pi/go/src/runtime/proc.go:304 +0xdc fp=0x219af98 sp=0x219af84 pc=0x40358
runtime.gcBgMarkWorker(0x2024600)
        /home/pi/go/src/runtime/mgc.go:1846 +0xd8 fp=0x219afe4 sp=0x219af98 pc=0x2b05c
runtime.goexit()
        /home/pi/go/src/runtime/asm_arm.s:864 +0x4 fp=0x219afe4 sp=0x219afe4 pc=0x6a008
created by runtime.gcBgMarkStartWorkers
        /home/pi/go/src/runtime/mgc.go:1794 +0x68

goroutine 131 [timer goroutine (idle)]:
runtime.gopark(0x3b7408, 0x60de70, 0x1415, 0x1)
        /home/pi/go/src/runtime/proc.go:304 +0xdc fp=0x2196f90 sp=0x2196f7c pc=0x40358
runtime.goparkunlock(...)
        /home/pi/go/src/runtime/proc.go:310
runtime.timerproc(0x60de70)
        /home/pi/go/src/runtime/time.go:300 +0x364 fp=0x2196fe4 sp=0x2196f90 pc=0x5bdb8
runtime.goexit()
        /home/pi/go/src/runtime/asm_arm.s:864 +0x4 fp=0x2196fe4 sp=0x2196fe4 pc=0x6a008
created by runtime.(*timersBucket).addtimerLocked
        /home/pi/go/src/runtime/time.go:166 +0x174

goroutine 101 [timer goroutine (idle)]:
runtime.gopark(0x3b7408, 0x60de30, 0x1415, 0x1)
        /home/pi/go/src/runtime/proc.go:304 +0xdc fp=0x254d790 sp=0x254d77c pc=0x40358
runtime.goparkunlock(...)
        /home/pi/go/src/runtime/proc.go:310
runtime.timerproc(0x60de30)
        /home/pi/go/src/runtime/time.go:300 +0x364 fp=0x254d7e4 sp=0x254d790 pc=0x5bdb8
runtime.goexit()
        /home/pi/go/src/runtime/asm_arm.s:864 +0x4 fp=0x254d7e4 sp=0x254d7e4 pc=0x6a008
created by runtime.(*timersBucket).addtimerLocked
        /home/pi/go/src/runtime/time.go:166 +0x174

goroutine 46 [runnable]:
runtime.notetsleepg(0x60dec4, 0x617de3, 0x0, 0x1)
        /home/pi/go/src/runtime/lock_futex.go:227 +0x24 fp=0x202af90 sp=0x202af78 pc=0x19df8
runtime.timerproc(0x60deb0)
        /home/pi/go/src/runtime/time.go:308 +0x42c fp=0x202afe4 sp=0x202af90 pc=0x5be80
runtime.goexit()
        /home/pi/go/src/runtime/asm_arm.s:864 +0x4 fp=0x202afe4 sp=0x202afe4 pc=0x6a008
created by runtime.(*timersBucket).addtimerLocked
        /home/pi/go/src/runtime/time.go:166 +0x174

goroutine 962 [syscall]:
runtime.sigtrampgo(0x11, 0x2009c88, 0x2009d08)
        /home/pi/go/src/runtime/signal_unix.go:293 +0x3c fp=0x2009c78 sp=0x2009c24 pc=0x53074
runtime: unexpected return pc for runtime.sigtramp called from 0x7ed1c788
stack: frame={sp:0x2009c78, fp:0x2009c88} stack=[0x21ae000,0x21b0000)

runtime.sigtramp(0x0, 0x1, 0x1e7f, 0x3e8, 0x0, 0x1, 0x0, 0x0, 0x0, 0x0, ...)
        /home/pi/go/src/runtime/sys_linux_arm.s:449 +0x28 fp=0x2009c88 sp=0x2009c78 pc=0x6af74
created by cmd/go/internal/work.(*Builder).Do
        /home/pi/go/src/cmd/go/internal/work/exec.go:164 +0x314

goroutine 963 [syscall]:
runtime.sigtrampgo(0x11, 0x20fdc88, 0x20fdd08)
        /home/pi/go/src/runtime/signal_unix.go:293 +0x3c fp=0x20fdc78 sp=0x20fdc24 pc=0x53074
runtime: unexpected return pc for runtime.sigtramp called from 0x7ed1c788
stack: frame={sp:0x20fdc78, fp:0x20fdc88} stack=[0x2562000,0x2564000)

runtime.sigtramp(0x0, 0x1, 0x1e7d, 0x3e8, 0x0, 0x1, 0x0, 0x0, 0x0, 0x0, ...)
        /home/pi/go/src/runtime/sys_linux_arm.s:449 +0x28 fp=0x20fdc88 sp=0x20fdc78 pc=0x6af74
created by cmd/go/internal/work.(*Builder).Do
        /home/pi/go/src/cmd/go/internal/work/exec.go:164 +0x314

runtime stack:
runtime.throw(0x38b338, 0x20)
        /home/pi/go/src/runtime/panic.go:774 +0x5c fp=0x7eadf2e0 sp=0x7eadf2cc pc=0x3df88
runtime.newstack()
        /home/pi/go/src/runtime/stack.go:957 +0x9cc fp=0x7eadf3a8 sp=0x7eadf2e0 pc=0x57204
runtime.morestack()
        /home/pi/go/src/runtime/asm_arm.s:420 +0x60 fp=0x7eadf3ac sp=0x7eadf3a8 pc=0x683cc

runtime stack:
runtime.throw(0x38b338, 0x20)
        /home/pi/go/src/runtime/panic.go:774 +0x5c fp=0x203df20 sp=0x203df0c pc=0x3df88
runtime.newstack()
        /home/pi/go/src/runtime/stack.go:957 +0x9cc fp=0x203dfe8 sp=0x203df20 pc=0x57204
runtime.morestack()
        /home/pi/go/src/runtime/asm_arm.s:420 +0x60 fp=0x203dfec sp=0x203dfe8 pc=0x683cc
go tool dist: FAILED: /home/pi/go/pkg/tool/linux_arm/go_bootstrap install -gcflags=all= -ldflags=all= -i cmd/asm cmd/cgo cmd/compile cmd/link: exit status 2

Please don’t reply on this GitHub thread. Visit golang.org/cl/192937.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2019-09-06T00:02:55Z

Message from Ian Lance Taylor:

Patch Set 2:

(4 comments)

I roughly reimplemented the patch following your suggestion, and added a test case.
However make.bash then started emitting a bunch of errors saying runtime: unexpected return pc for runtime.sigtramp.
Do you have any ideas how to fix this?

You need to add a "//go:nosplit" comment before inVDSOPage.

Please don’t reply on this GitHub thread. Visit golang.org/cl/192937.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2019-09-06T06:48:48Z

Message from Yuichi Nishiwaki:

Patch Set 3:

Aw, I was misunderstanding the document.
info.si_addr is not a pointer pointing to the program counter the signal interrupted at, but it contains the address that caused memory fault.
So if your user program touch memory at 0xdeadbeef which is not allocated it causes a segv signal with info.si_addr 0xdeadbeef.
info.si_addr is zero-cleared almost all time and the current patch is useless.
I'm not aware of any portable way to retrieve suspended pc in a handler.
Possibly I will force-push back the first patch unless I come up with any other workaround :(

Please don’t reply on this GitHub thread. Visit golang.org/cl/192937.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2019-09-06T07:49:27Z

This PR (HEAD: 808b03f) has been imported to Gerrit for code review.

Please visit https://go-review.googlesource.com/c/go/+/192937 to see it.

Tip: You can toggle comments from me using the comments slash command (e.g. /comments off)
See the Wiki page for more info

gopherbot · 2019-09-06T18:07:56Z

Message from Ian Lance Taylor:

Patch Set 4:

Aw, I was misunderstanding the document.
info.si_addr is not a pointer pointing to the program counter the signal interrupted at, but it contains the address that caused memory fault.
So if your user program touch memory at 0xdeadbeef which is not allocated it causes a segv signal with info.si_addr 0xdeadbeef.
info.si_addr is zero-cleared almost all time and the current patch is useless.
I'm not aware of any portable way to retrieve suspended pc in a handler.
Possibly I will force-push back the first patch unless I come up with any other workaround :(

You can get the PC at which the signal occurred via
c := &sigctxt{info, ctx}
c.sigpc()
as seen in the way we handle SIGPROF in the g == nil case.

Please don’t reply on this GitHub thread. Visit golang.org/cl/192937.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2019-09-09T04:59:30Z

This PR (HEAD: 4b53547) has been imported to Gerrit for code review.

Please visit https://go-review.googlesource.com/c/go/+/192937 to see it.

Tip: You can toggle comments from me using the comments slash command (e.g. /comments off)
See the Wiki page for more info

gopherbot · 2019-09-09T05:06:21Z

Message from Yuichi Nishiwaki:

Patch Set 4:

Patch Set 4:

Aw, I was misunderstanding the document.
info.si_addr is not a pointer pointing to the program counter the signal interrupted at, but it contains the address that caused memory fault.
So if your user program touch memory at 0xdeadbeef which is not allocated it causes a segv signal with info.si_addr 0xdeadbeef.
info.si_addr is zero-cleared almost all time and the current patch is useless.
I'm not aware of any portable way to retrieve suspended pc in a handler.
Possibly I will force-push back the first patch unless I come up with any other workaround :(

You can get the PC at which the signal occurred via
c := &sigctxt{info, ctx}
c.sigpc()
as seen in the way we handle SIGPROF in the g == nil case.

It works perfectly in my environment!
I confirmed the result of the test case I added changed changed before and after the commit. (FAIL -> PASS, of course)
I have updated and force-pushed the change to the thread.
Could you check it out please?

Please don’t reply on this GitHub thread. Visit golang.org/cl/192937.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2019-09-10T04:51:19Z

Message from Ian Lance Taylor:

Patch Set 5:

(2 comments)

Thanks. Besides small change below, please update the description to describe the current code. Also we usually put the Fixes line at the end of the description.

Please don’t reply on this GitHub thread. Visit golang.org/cl/192937.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2019-09-10T05:33:07Z

Message from Yuichi Nishiwaki:

Patch Set 6: Commit message was updated.

Please don’t reply on this GitHub thread. Visit golang.org/cl/192937.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2019-09-10T06:32:38Z

This PR (HEAD: dac3021) has been imported to Gerrit for code review.

Please visit https://go-review.googlesource.com/c/go/+/192937 to see it.

Tip: You can toggle comments from me using the comments slash command (e.g. /comments off)
See the Wiki page for more info

gopherbot · 2019-09-10T06:34:41Z

Message from Yuichi Nishiwaki:

Patch Set 7:

Patch Set 5:

(2 comments)

Thanks. Besides small change below, please update the description to describe the current code. Also we usually put the Fixes line at the end of the description.

Updated the patch and the description.

Please don’t reply on this GitHub thread. Visit golang.org/cl/192937.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2019-09-10T14:12:42Z

Message from Ian Lance Taylor:

Patch Set 8:

Updated the patch and the description.

Thanks. The description doesn't seem to be updated. You need to update the initial comment in GitHub to get that reflected in Gerrit. See https://golang.org/wiki/CommitMessage.

Please don’t reply on this GitHub thread. Visit golang.org/cl/192937.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2019-09-10T14:24:25Z

Message from Yuichi Nishiwaki:

Patch Set 8:

Patch Set 8:

Updated the patch and the description.

Thanks. The description doesn't seem to be updated. You need to update the initial comment in GitHub to get that reflected in Gerrit. See https://golang.org/wiki/CommitMessage.

Seems like my edits on Gerrit disappeared. I have just updated again.

Please don’t reply on this GitHub thread. Visit golang.org/cl/192937.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2019-09-10T14:34:59Z

Message from Ian Lance Taylor:

Patch Set 9:

(1 comment)

Please don’t reply on this GitHub thread. Visit golang.org/cl/192937.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2019-09-10T15:10:56Z

This PR (HEAD: 00b1081) has been imported to Gerrit for code review.

Please visit https://go-review.googlesource.com/c/go/+/192937 to see it.

Tip: You can toggle comments from me using the comments slash command (e.g. /comments off)
See the Wiki page for more info

gopherbot · 2019-09-10T15:14:55Z

Message from Yuichi Nishiwaki:

Patch Set 10:

Patch Set 9:

(1 comment)

OK, reflected your comment.

Please don’t reply on this GitHub thread. Visit golang.org/cl/192937.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2019-09-10T20:38:52Z

Message from Ian Lance Taylor:

Patch Set 10:

(1 comment)

Please don’t reply on this GitHub thread. Visit golang.org/cl/192937.
After addressing review feedback, remember to publish your drafts!

The crash occurs when go runtime calls a VDSO function (say __vdso_clock_gettime) and a signal arrives to that thread. Since VDSO functions temporarily destroy the G register (R10), Go functions asynchronously executed in that thread (i.e. Go's signal handler) can try to load data from the destroyed G, which causes segmentation fault.

gopherbot · 2019-09-11T02:26:07Z

This PR (HEAD: 28ce42c) has been imported to Gerrit for code review.

Please visit https://go-review.googlesource.com/c/go/+/192937 to see it.

Tip: You can toggle comments from me using the comments slash command (e.g. /comments off)
See the Wiki page for more info

gopherbot · 2019-09-11T03:16:54Z

Message from Ian Lance Taylor:

Patch Set 11: Run-TryBot+1

Please don’t reply on this GitHub thread. Visit golang.org/cl/192937.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2019-09-11T03:16:55Z

Message from Gobot Gobot:

Patch Set 11:

TryBots beginning. Status page: https://farmer.golang.org/try?commit=60a69abc

Please don’t reply on this GitHub thread. Visit golang.org/cl/192937.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2019-09-11T03:27:01Z

Message from Gobot Gobot:

Patch Set 11: TryBot-Result+1

TryBots are happy.

Please don’t reply on this GitHub thread. Visit golang.org/cl/192937.
After addressing review feedback, remember to publish your drafts!

As discussed in #32912, a crash occurs when go runtime calls a VDSO function (say __vdso_clock_gettime) and a signal arrives to that thread. Since VDSO functions temporarily destroy the G register (R10), Go functions asynchronously executed in that thread (i.e. Go's signal handler) can try to load data from the destroyed G, which causes segmentation fault. To fix the issue a guard is inserted in front of sigtrampgo, so that the control escapes from signal handlers without touching G in case the signal occurred in the VDSO context. The test case included in the patch is take from discussion in a relevant thread on github: #32912 (comment). This patch not only fixes the issue on AArch64 but also that on 32bit ARM. Fixes #32912 Change-Id: I657472e54b7aa3c617fabc5019ce63aa4105624a GitHub-Last-Rev: 28ce42c GitHub-Pull-Request: #34030 Reviewed-on: https://go-review.googlesource.com/c/go/+/192937 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>

gopherbot · 2019-09-11T03:35:59Z

Message from Ian Lance Taylor:

Patch Set 11: Code-Review+2

Thanks for your patience with this.

Please don’t reply on this GitHub thread. Visit golang.org/cl/192937.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2019-09-11T03:42:03Z

This PR is being closed because golang.org/cl/192937 has been merged.

This commit fixes issue golang#34391, which is due to an incorrect patch merged in golang#34030. sigtrampgo is modified to record incoming signals in a globally shared atomic bitmask during when the G register is clobbered. When the execution exits from vdso it checks if there is a pending signal it re-raises them to its own process.

This commit fixes issue golang#34391, which is due to an incorrect patch merged in golang#34030. sigtrampgo is modified to record incoming signals in a globally shared atomic bitmask when the G register is clobbered. When the execution exits from vdso it checks if there is a pending signal and in that case it re-raises them to its own process.

googlebot added the cla: no Used by googlebot to label PRs as having an invalid CLA. The text of this label should not change. label Sep 3, 2019

googlebot added cla: yes Used by googlebot to label PRs as having a valid CLA. The text of this label should not change. and removed cla: no Used by googlebot to label PRs as having an invalid CLA. The text of this label should not change. labels Sep 3, 2019

nyuichi force-pushed the fix-32912 branch from 6ccc156 to 3a273a9 Compare September 5, 2019 05:54

add test case for golang#32912

5d04e76

nyuichi force-pushed the fix-32912 branch from 3a273a9 to 808b03f Compare September 6, 2019 07:49

nyuichi force-pushed the fix-32912 branch from 808b03f to 4b53547 Compare September 9, 2019 04:58

nyuichi force-pushed the fix-32912 branch from 4b53547 to dac3021 Compare September 10, 2019 06:32

nyuichi force-pushed the fix-32912 branch from dac3021 to 00b1081 Compare September 10, 2019 15:10

nyuichi force-pushed the fix-32912 branch from 00b1081 to 28ce42c Compare September 11, 2019 02:25

gopherbot closed this Sep 11, 2019

nyuichi mentioned this pull request Sep 19, 2019

runtime: infinite loop in lockextra on linux/arm #34391

Closed

nyuichi mentioned this pull request Oct 18, 2019

runtime: WIP: fix infinite loop in lockextra on linux/arm #34979

Closed

alvin-huang mentioned this pull request Jul 13, 2021

ci: set CGO_ENABLED: 0 for arm/arm64 builds hashicorp/consul#10610

Closed

alvin-huang mentioned this pull request Sep 16, 2021

ci: dockerfile download arm instead of armv6 binary hashicorp/consul-ecs#26

Merged

runtime: fix crash during VDSO calls on arm #34030

runtime: fix crash during VDSO calls on arm #34030

Conversation

nyuichi commented Sep 3, 2019 • edited Loading

googlebot commented Sep 3, 2019

What to do if you already signed the CLA

Individual signers

Corporate signers

nyuichi commented Sep 3, 2019

googlebot commented Sep 3, 2019

gopherbot commented Sep 3, 2019

gopherbot commented Sep 3, 2019

gopherbot commented Sep 3, 2019

gopherbot commented Sep 3, 2019

gopherbot commented Sep 3, 2019

gopherbot commented Sep 3, 2019

gopherbot commented Sep 3, 2019

gopherbot commented Sep 3, 2019

gopherbot commented Sep 3, 2019

gopherbot commented Sep 5, 2019

gopherbot commented Sep 5, 2019

gopherbot commented Sep 6, 2019

gopherbot commented Sep 6, 2019

gopherbot commented Sep 6, 2019

gopherbot commented Sep 6, 2019

gopherbot commented Sep 9, 2019

gopherbot commented Sep 9, 2019

gopherbot commented Sep 10, 2019

gopherbot commented Sep 10, 2019

gopherbot commented Sep 10, 2019

gopherbot commented Sep 10, 2019

gopherbot commented Sep 10, 2019

gopherbot commented Sep 10, 2019

gopherbot commented Sep 10, 2019

gopherbot commented Sep 10, 2019

gopherbot commented Sep 10, 2019

gopherbot commented Sep 10, 2019

gopherbot commented Sep 11, 2019

gopherbot commented Sep 11, 2019

gopherbot commented Sep 11, 2019

gopherbot commented Sep 11, 2019

gopherbot commented Sep 11, 2019

gopherbot commented Sep 11, 2019

nyuichi commented Sep 3, 2019 •

edited

Loading