Merge upstream release-branch.go1.16 into microsoft/release-branch.go1.16
#183
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… adjustTimers is 0 This avoids a race when a new timerModifiedEarlier timer is created by a different goroutine. For #47329 Fixes #47332 Change-Id: I6f6c87b4a9b5491b201c725c10bc98e23e0ed9d1 Reviewed-on: https://go-review.googlesource.com/c/go/+/336432 Trust: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com> (cherry picked from commit 798ec73) Reviewed-on: https://go-review.googlesource.com/c/go/+/336689
In CL 336432 we changed adjusttimers so that it no longer cleared timerModifiedEarliest if there were no timersModifiedEarlier timers. This caused some Google internal tests to time out, presumably due to the increased contention on timersLock. We can avoid that by simply not skipping the loop in adjusttimers, which lets us safely clear timerModifiedEarliest. And if we don't skip the loop, then there isn't much reason to keep the count of timerModifiedEarlier timers at all. So remove it. The effect will be that for programs that create some timerModifiedEarlier timers and then remove them all, the program will do an occasional additional loop over all the timers. And, programs that have some timerModifiedEarlier timers will always loop over all the timers, without the quicker exit when they have all been seen. But the loops should not occur all that often, due to timerModifiedEarliest. For #47329 For #47332 Change-Id: I7b244c1244d97b169a3c7fbc8f8a8b115731ddee Reviewed-on: https://go-review.googlesource.com/c/go/+/337309 Trust: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com> (cherry picked from commit bfbb288) Reviewed-on: https://go-review.googlesource.com/c/go/+/338649
…y request body Reading from an incoming request body after the request handler aborts with a panic can cause a panic, becuse http.Server does not (contrary to its documentation) close the request body in this case. Always close the incoming request body in ReverseProxy.ServeHTTP to ensure that any in-flight outgoing requests using the body do not read from it. Fixes #47474 Updates #46866 Fixes CVE-2021-36221 Change-Id: I310df269200ad8732c5d9f1a2b00de68725831df Reviewed-on: https://go-review.googlesource.com/c/go/+/333191 Trust: Damien Neil <dneil@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Filippo Valsorda <filippo@golang.org> (cherry picked from commit b7a85e0) Reviewed-on: https://go-review.googlesource.com/c/go/+/338551 Trust: Filippo Valsorda <filippo@golang.org> Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Damien Neil <dneil@google.com>
…e when in a cycle When hitting an import cycle in reusePackage, and there is already an error set, make sure IsImportCycle is set so that we don't end up stuck in a loop. Updates #25830 Fixes #47348 Change-Id: Iba966aea4a637dfc34ee22782a477209ac48c9bd Reviewed-on: https://go-review.googlesource.com/c/go/+/301289 Trust: Roland Shoemaker <roland@golang.org> Run-TryBot: Roland Shoemaker <roland@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com> Reviewed-by: Jay Conrod <jayconrod@google.com> TryBot-Result: Go Bot <gobot@golang.org> (cherry picked from commit cdd08e6) Reviewed-on: https://go-review.googlesource.com/c/go/+/336649 Trust: Bryan C. Mills <bcmills@google.com> Run-TryBot: Bryan C. Mills <bcmills@google.com>
In CL 326211 a change was made to switch "go.map.zero" symbols from non-pkg DUPOK symbols to hashed symbols. The intent of this change was ensure that in cases where there are multiple competing go.map.zero symbols feeding into a link, the largest map.zero symbol is selected. The change was buggy, however, and resulted in duplicate symbols in the final binary (see bug cited below for details). This duplication was relatively benign for linux/ELF, but causes duplicate definition errors on Windows. This patch switches "go.map.zero" symbols back from hashed symbols to non-pkg DUPOK symbols, and updates the relevant code in the loader to ensure that we do the right thing when there are multiple competing DUPOK symbols with different sizes. Fixes #47289. Change-Id: I8aeb910c65827f5380144d07646006ba553c9251 Reviewed-on: https://go-review.googlesource.com/c/go/+/334930 Trust: Than McIntosh <thanm@google.com> Run-TryBot: Than McIntosh <thanm@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> (cherry picked from commit 49402be) Reviewed-on: https://go-review.googlesource.com/c/go/+/335629
…standard calls on ARM64 On ARM64, (external) linker generated trampoline may clobber R16 and R17. In CL 183842 we change Duff's devices not to use those registers. However, this is not enough. The register allocator also needs to know that these registers may be clobbered in any calls that don't follow the standard Go calling convention. This include Duff's devices and the write barrier. Fixes #46928. Updates #32773. Change-Id: Ia52a891d9bbb8515c927617dd53aee5af5bd9aa4 Reviewed-on: https://go-review.googlesource.com/c/go/+/184437 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Meng Zhuo <mzh@golangcn.org> Reviewed-by: Keith Randall <khr@golang.org> Trust: Meng Zhuo <mzh@golangcn.org> (cherry picked from commit 11b4aee) Reviewed-on: https://go-review.googlesource.com/c/go/+/331029 Trust: Cherry Mui <cherryyz@google.com> Run-TryBot: Cherry Mui <cherryyz@google.com>
Updates #46528 Fixes #46551 Change-Id: I2453d321ece878ea7823865758aa4a16b3ed7fe8 Reviewed-on: https://go-review.googlesource.com/c/go/+/325430 Reviewed-by: Bryan C. Mills <bcmills@google.com> Run-TryBot: Bryan C. Mills <bcmills@google.com> Trust: Heschi Kreinick <heschi@google.com> Trust: Dmitri Shuralyov <dmitshur@golang.org> TryBot-Result: Go Bot <gobot@golang.org> (cherry picked from commit e552a6d) Reviewed-on: https://go-review.googlesource.com/c/go/+/334371 Trust: Bryan C. Mills <bcmills@google.com> Reviewed-by: Jay Conrod <jayconrod@google.com> Reviewed-by: Michael Matloob <matloob@golang.org>
…for package paths in 'go mod vendor' copyMetadata walk-up to parent directory until the pkg become modPath. But pkg should be slash-separated paths. It have to use path.Dir instead of filepath.Dir. Updates #46867 Fixes #47015 Change-Id: I44cf1429fe52379a7415b94cc30ae3275cc430e8 Reviewed-on: https://go-review.googlesource.com/c/go/+/330149 Reviewed-by: Bryan C. Mills <bcmills@google.com> Trust: Bryan C. Mills <bcmills@google.com> Trust: Alexander Rakoczy <alex@golang.org> Trust: Carlos Amedee <carlos@golang.org> Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Go Bot <gobot@golang.org> (cherry picked from commit 835d86a) Reviewed-on: https://go-review.googlesource.com/c/go/+/332329 Reviewed-by: Jay Conrod <jayconrod@google.com>
This patch reinstates a fix for PowerPC with regard to making VDSO calls while receiving a signal, and subsequently crashing. The crash happens because certain VDSO calls can modify the r30 register, which is where g is stored. This change was reverted for PowerPC because r30 is supposed to be a non-volatile register. This is true, but that only makes a guarantee across function calls, but not "within" a function call. This patch was seemingly fine before because the Linux kernel still had hand rolled assembly VDSO function calls, however with a recent change to C function calls it seems the compiler used can generate instructions which temporarily clobber r30. This means that when we receive a signal during one of these calls the value of r30 will not be the g as the runtime expects, causing a segfault. You can see from this assembly dump how the register is clobbered during the call: (the following is from a 5.13rc2 kernel) ``` Dump of assembler code for function __cvdso_clock_gettime_data: 0x00007ffff7ff0700 <+0>: cmplwi r4,15 0x00007ffff7ff0704 <+4>: bgt 0x7ffff7ff07f0 <__cvdso_clock_gettime_data+240> 0x00007ffff7ff0708 <+8>: li r9,1 0x00007ffff7ff070c <+12>: slw r9,r9,r4 0x00007ffff7ff0710 <+16>: andi. r10,r9,2179 0x00007ffff7ff0714 <+20>: beq 0x7ffff7ff0810 <__cvdso_clock_gettime_data+272> 0x00007ffff7ff0718 <+24>: rldicr r10,r4,4,59 0x00007ffff7ff071c <+28>: lis r9,32767 0x00007ffff7ff0720 <+32>: std r30,-16(r1) 0x00007ffff7ff0724 <+36>: std r31,-8(r1) 0x00007ffff7ff0728 <+40>: add r6,r3,r10 0x00007ffff7ff072c <+44>: ori r4,r9,65535 0x00007ffff7ff0730 <+48>: lwz r8,0(r3) 0x00007ffff7ff0734 <+52>: andi. r9,r8,1 0x00007ffff7ff0738 <+56>: bne 0x7ffff7ff07d0 <__cvdso_clock_gettime_data+208> 0x00007ffff7ff073c <+60>: lwsync 0x00007ffff7ff0740 <+64>: mftb r30 <---- RIGHT HERE => 0x00007ffff7ff0744 <+68>: ld r12,40(r6) ``` What I believe is happening is that the kernel changed the PowerPC VDSO calls to use standard C calls instead of using hand rolled assembly. The hand rolled assembly calls never touched r30, so this change was safe to roll back. That does not seem to be the case anymore as on the 5.13rc2 kernel the compiler *is* generating assembly which modifies r30, making this change again unsafe and causing a crash when the program receives a signal during these calls (which will happen often due to async preempt). This change happened here: https://lwn.net/ml/linux-kernel/235e5571959cfa89ced081d7e838ed5ff38447d2.1601365870.git.christophe.leroy@csgroup.eu/. I realize this was reverted due to unexplained hangs in PowerPC builders, but I think we should reinstate this change and investigate those issues separately: golang/go@f4ca3c1 Fixes #46858 Change-Id: Ib18d7bbfc80a1a9cb558f0098878d41081324b52 GitHub-Last-Rev: c3002bcfca3ef58b27485e31328e6297b7a9dfe7 GitHub-Pull-Request: golang/go#46767 Reviewed-on: https://go-review.googlesource.com/c/go/+/328110 Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Trust: Lynn Boger <laboger@linux.vnet.ibm.com> (cherry picked from commit 16e82be) Reviewed-on: https://go-review.googlesource.com/c/go/+/334410 Run-TryBot: Cherry Mui <cherryyz@google.com>
…estWhenSharingConnection This test made many requests over the same connection for 10 seconds, trusting that this will exercise the request cancelation race from #41600. Change the test to exhibit the specific race in a targeted fashion with only two requests. Fixes #47535. Updates #41600. Updates #47016. Change-Id: If99c9b9331ff645f6bb67fe9fb79b8aab8784710 Reviewed-on: https://go-review.googlesource.com/c/go/+/339594 Trust: Damien Neil <dneil@google.com> Run-TryBot: Damien Neil <dneil@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Heschi Kreinick <heschi@google.com> (cherry picked from commit 6e73886) Reviewed-on: https://go-review.googlesource.com/c/go/+/339830
Change-Id: I5a8616596c53b43f60487e19385b6a60af1addfe Reviewed-on: https://go-review.googlesource.com/c/go/+/339451 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Alexander Rakoczy <alex@golang.org> Trust: Damien Neil <dneil@google.com> Trust: Carlos Amedee <carlos@golang.org>
…llation test Change the TestInstallationImporter testpoint to query type information for sort.Search instead of sort.Ints. The latter function changed recently (1.16 timeframe), parameter "a" is now "x". A better candidate for this sort of query is sort.Search, which has been stable for a while. Fixes #47610. Change-Id: I314476eac0b0802f86f5cbce32195cab2926db83 Reviewed-on: https://go-review.googlesource.com/c/go/+/294290 Trust: Than McIntosh <thanm@google.com> Run-TryBot: Than McIntosh <thanm@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> (cherry picked from commit 0f66fb7) Reviewed-on: https://go-review.googlesource.com/c/go/+/340952
… helpers On Linux ARMv6 and below runtime/internal/atomic.Cas calls into a kernel cas helper at a fixed address. If a SIGPROF arrives while executing the kernel helper, the sigprof lostAtomic logic will miss that we are potentially in the spinlock critical section, which could cause a deadlock when using atomics later in sigprof. For #47505 Fixes #47675 Change-Id: If8ba0d0fc47e45d4e6c68eca98fac4c6ed4e43c1 Reviewed-on: https://go-review.googlesource.com/c/go/+/341889 Trust: Michael Pratt <mpratt@google.com> Run-TryBot: Michael Pratt <mpratt@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Go Bot <gobot@golang.org> (cherry picked from commit 20a620f) Reviewed-on: https://go-review.googlesource.com/c/go/+/341853
microsoft-golang-bot
requested review from
microsoft-golang-review-bot and
a team
as code owners
microsoft-golang-review-bot
approved these changes
Aug 19, 2021
microsoft-golang-review-bot
merged commit 46aa5b6
into
microsoft:microsoft/release-branch.go1.16
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
🔃 This is an automatically generated PR merging upstream
release-branch.go1.16intomicrosoft/release-branch.go1.16.This PR should auto-merge itself when PR validation passes. If CI fails and you need to make fixups, be sure to use a merge commit, not a squash or rebase!
After these changes, the difference between upstream and the branch is: