Michael Pratt [Wed, 13 Jul 2022 15:48:04 +0000 (11:48 -0400)]
[release-branch.go1.17] runtime: clear timerModifiedEarliest when last timer is deleted
timerModifiedEarliest contains the lowest possible expiration for a
modified earlier timer, which may be earlier than timer0When because we
haven't yet updated the heap. Note "may", as the modified earlier timer
that set timerModifiedEarliest may have since been modified later or
deleted.
We can clear timerModifiedEarliest when the last timer is deleted
because by definition there must not be any modified earlier timers.
Why does this matter? checkTimersNoP claims that there is work to do if
timerModifiedEarliest has passed, causing findRunnable to loop back
around to checkTimers. But the code to clean up timerModifiedEarliest in
checkTimers (i.e., the call to adjusttimers) is conditional behind a
check that len(pp.timers) > 0.
Without clearing timerModifiedEarliest, a spinning M that would
otherwise go to sleep will busy loop in findRunnable until some other
work is available.
Note that changing the condition on the call to adjusttimers would also
be a valid fix. I took this approach because it feels a bit cleaner to
clean up timerModifiedEarliest as soon as it is known to be irrelevant.
For #51654.
Fixes #53846.
Change-Id: I3f3787c67781cac7ce87939c5706cef8db927dd5
Reviewed-on: https://go-review.googlesource.com/c/go/+/417434
Auto-Submit: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
(cherry picked from commit c006b7ac2765252f397dec40fef610a3c17d956d)
Reviewed-on: https://go-review.googlesource.com/c/go/+/417476
Cherry Mui [Fri, 15 Apr 2022 16:23:06 +0000 (12:23 -0400)]
[release-branch.go1.17] runtime: use saved LR when unwinding through morestack
On LR machine, consider F calling G calling H, which grows stack.
The stack looks like
...
G's frame:
... locals ...
saved LR = return PC in F <- SP points here at morestack
H's frame (to be created)
At morestack, we save
gp.sched.pc = H's morestack call
gp.sched.sp = H's entry SP (the arrow above)
gp.sched.lr = return PC in G
Currently, when unwinding through morestack (if _TraceJumpStack
is set), we switch PC and SP but not LR. We then have
frame.pc = H's morestack call
frame.sp = H's entry SP (the arrow above)
As LR is not set, we load it from stack at *sp, so
frame.lr = return PC in F
As the SP hasn't decremented at the morestack call,
frame.fp = frame.sp = H's entry SP
Unwinding a frame, we have
frame.pc = old frame.lr = return PC in F
frame.sp = old frame.fp = H's entry SP a.k.a. G's SP
The PC and SP don't match. The unwinding will go off if F and G
have different frame sizes.
Fix this by preserving the LR when switching stack.
Also add code to detect infinite loop in unwinding.
TODO: add some test. I can reproduce the infinite loop (or throw
with added check) but the frequency is low.
Limit nested parsing to 100,000, which prevents stack exhaustion when
parsing deeply nested statements, types, and expressions. Also limit
the scope depth to 1,000 during object resolution.
Thanks to Juho Nurminen of Mattermost for reporting this issue.
Michael Pratt [Tue, 28 Jun 2022 20:32:50 +0000 (16:32 -0400)]
[release-branch.go1.17] runtime: add race annotations to cbs.lock
cbs.lock protects a map. The map implementation is race instrumented
regardless of which package is it called from.
lock/unlock are not automatically race instrumented, so we can trigger
race false positives without manually annotating our lock acquire and
release.
compileCallback is used during initialization before the P is available,
at which point raceacquire will crash during a racecallback to get the
race proc. Thus we skip instrumentation until scheduler initialization
is complete.
Fixes #53612.
For #50249.
Change-Id: Ie49227c9e9210ffbf0aee65f86f2b7b6a2f64638
Reviewed-on: https://go-review.googlesource.com/c/go/+/414518
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
(cherry picked from commit 20760cff001e9acc05627dfeab42ea50b57920e6)
Reviewed-on: https://go-review.googlesource.com/c/go/+/415197
Michael Pratt [Tue, 28 Jun 2022 19:17:12 +0000 (15:17 -0400)]
[release-branch.go1.17] runtime: add race annotations to metricsSema
metricsSema protects the metrics map. The map implementation is race
instrumented regardless of which package is it called from.
semacquire/semrelease are not automatically race instrumented, so we can
trigger race false positives without manually annotating our lock
acquire and release.
See similar instrumentation on trace.shutdownSema and reflectOffs.lock.
Fixes #53589.
For #53542.
Change-Id: Ia3fd239ac860e037d09c7cb9c4ad267391e70705
Reviewed-on: https://go-review.googlesource.com/c/go/+/414517
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
(cherry picked from commit d6481d5b9662b29453004204746945a93a6b4eb2)
Reviewed-on: https://go-review.googlesource.com/c/go/+/415196
Keith Randall [Tue, 21 Jun 2022 00:06:09 +0000 (17:06 -0700)]
[release-branch.go1.17] cmd/compile: allow 128-bit values to be spilled
We sometimes use 16-byte load+store to move values around in memory.
In rare circumstances, the loaded value must be spilled because the
store can't happen yet.
In that case, we need to be able to spill the 16-byte value.
Fixes #53470
Change-Id: I09fd08e11a63c6ba3ef781d3f5ede237e9b0132e
Reviewed-on: https://go-review.googlesource.com/c/go/+/413294 Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com>
(cherry picked from commit c2d373d5d1802d7479f3c81dcf01d41bef3646dd)
Reviewed-on: https://go-review.googlesource.com/c/go/+/413456 Reviewed-by: Carlos Amedee <carlos@golang.org>
Michael Anthony Knyszek [Thu, 9 Jun 2022 18:25:01 +0000 (18:25 +0000)]
[release-branch.go1.17] runtime: store consistent total allocation stats as uint64
Currently the consistent total allocation stats are managed as uintptrs,
which means they can easily overflow on 32-bit systems. Fix this by
storing these stats as uint64s. This will cause some minor performance
degradation on 32-bit systems, but there really isn't a way around this,
and it affects the correctness of the metrics we export.
For #52680.
Fixes #52688.
Change-Id: I8b1926116e899ae9f03d58e0320bcb9264945b3e
Reviewed-on: https://go-review.googlesource.com/c/go/+/411496
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com>
Cherry Mui [Tue, 8 Feb 2022 19:46:58 +0000 (14:46 -0500)]
[release-branch.go1.17] cmd/dist: test cgo internal linking on darwin-arm64
CL 415074 disables testing cgo internal linking on all ARM64 but
Windows, because it doesn't work with newer GCC. But
- darwin-arm64 works, and it does not use GCC
- we don't support cgo internal linking on windows-arm64 anyway.
This CL fixes the condition.
Fixes #53050.
Change-Id: I9eb7b81ef75e482f5e95d2edae4863ba21396432
Reviewed-on: https://go-review.googlesource.com/c/go/+/384269
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
(cherry picked from commit e4ca3fa345a204b72a011b3634ddcfc09dcc68bc)
Reviewed-on: https://go-review.googlesource.com/c/go/+/415075 Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Benny Siegert [Sat, 5 Feb 2022 16:23:26 +0000 (17:23 +0100)]
[release-branch.go1.17] cmd/dist: skip internal linking tests on arm64
The previous workaround for issue #39466 only disabled this test for
Linux. However, the issue manifests for all arm64 systems with gcc 9.4
and above. The new netbsd-arm64 builder uses NetBSD-current with gcc
10.3, so it fails in the same way.
Updates #39466.
For #53050.
Change-Id: I276a99a5e60914e5c22f74a680e461bea17cfe92
Reviewed-on: https://go-review.googlesource.com/c/go/+/383554
Trust: Benny Siegert <bsiegert@gmail.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
(cherry picked from commit 1d6051380c1faa3e515db73c4cfe14f807e2c686)
Reviewed-on: https://go-review.googlesource.com/c/go/+/415074
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
[release-branch.go1.17] path/filepath: do not remove prefix "." when following path contains ":".
For #52476
Fixes #52478
Fixes CVE-2022-29804
Change-Id: I9eb72ac7dbccd6322d060291f31831dc389eb9bb
Reviewed-on: https://go-review.googlesource.com/c/go/+/401595
Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-on: https://go-review.googlesource.com/c/go/+/405235 Reviewed-by: Yasuhiro Matsumoto <mattn.jp@gmail.com>
David Taylor [Mon, 17 Jan 2022 21:54:17 +0000 (21:54 +0000)]
[release-branch.go1.17] crypto/tls: avoid extra allocations in steady-state Handshake calls
The Read and Write methods of *tls.Conn call Handshake
unconditionally, every time they are called, expecting it to only
perform a new handshake if required.
However in go 1.17 handshakeContext was extended to set up a
cancelable Context, and importantly did so prior to checking if a
handshake is required. This thus causes it to allocate on every call,
even in those that are no-ops when called in a Read or Write on an
established connection, sometimes leading to very large numbers of
allocations during reads.
This change adds an early return, prior to setting up the context or
proceeding into the handshakeMutex and checking the handshake error, if
the handshake status atomic indicates handshake is already complete.
As required by RFC 8446, section 4.6.1, ticket_age_add now holds a
random 32-bit value. Before this change, this value was always set
to 0.
This change also documents the reasoning for always setting
ticket_nonce to 0. The value ticket_nonce must be unique per
connection, but we only ever send one ticket per connection.
Russ Cox [Tue, 3 May 2022 19:14:56 +0000 (15:14 -0400)]
[release-branch.go1.17] os/exec: return clear error for missing cmd.Path
Following up on CL 403694, there is a bit of confusion about
when Path is and isn't set, along with now the exported Err field.
Catch the case where Path and Err (and lookPathErr) are all unset
and give a helpful error.
Updates #52574
Followup after #43724.
Fixes #53056
Fixes CVE-2022-30580
Change-Id: I03205172aef3801c3194f5098bdb93290c02b1b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/403759 Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Roland Shoemaker <roland@golang.org>
(cherry picked from commit 960ffa98ce73ef2c2060c84c7ac28d37a83f345e)
Reviewed-on: https://go-review.googlesource.com/c/go/+/408578
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Roland Shoemaker [Tue, 26 Apr 2022 02:02:35 +0000 (19:02 -0700)]
[release-branch.go1.17] crypto/rand: properly handle large Read on windows
Use the batched reader to chunk large Read calls on windows to a max of
1 << 31 - 1 bytes. This prevents an infinite loop when trying to read
more than 1 << 32 -1 bytes, due to how RtlGenRandom works.
This change moves the batched function from rand_unix.go to rand.go,
since it is now needed for both windows and unix implementations.
Cherry Mui [Tue, 24 May 2022 00:20:07 +0000 (20:20 -0400)]
[release-branch.go1.17] misc/cgo/testsanitizers: use buffered channel in tsan12.go
os/signal.Notify requires that "the caller must ensure that c has
sufficient buffer space to keep up with the expected signal rate"
as it does a nonblocking send when it receives a signal. The test
currently using a unbuffered channel, which means it may miss the
signal if the signal arrives before the channel receive operation.
Fixes #53042.
Updates #52998.
Change-Id: Icdcab9396d735506480ef880fb45a4669fa7cc8f
Reviewed-on: https://go-review.googlesource.com/c/go/+/407888 Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
(cherry picked from commit 62e130226767a088ace196da90a774c9a9d14689)
Reviewed-on: https://go-review.googlesource.com/c/go/+/408115
Bryan C. Mills [Tue, 8 Feb 2022 20:07:21 +0000 (15:07 -0500)]
[release-branch.go1.17] runtime: skip TestGdbBacktrace flakes matching a known GDB internal error
TestGdbBacktrace occasionally fails due to a GDB internal error.
We have observed the error on various linux builders since at least
October 2020, and it has been reported upstream at least twice.¹²
Since the bug is external to the Go project and does not appear to be
fixed upstream, this failure mode can only add noise.
Matthew Dempsky [Wed, 21 Jul 2021 18:43:57 +0000 (11:43 -0700)]
[release-branch.go1.17] runtime: mark TestGcSys as flaky
I don't know what this test is doing, but it very frequently flakes
for me while testing mundane compiler CLs. According to the issue log,
it's been flaky for ~3 years.
Updates #37331.
Fixes #52826.
Change-Id: I81c43ad646ee12d4c6561290a54e4bf637695bc6
Reviewed-on: https://go-review.googlesource.com/c/go/+/336349
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
(cherry picked from commit d8ceb133cac65b47c3f5bb292fbb28690c8b89a5)
Reviewed-on: https://go-review.googlesource.com/c/go/+/406974
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Keith Randall [Mon, 14 Feb 2022 22:57:55 +0000 (14:57 -0800)]
[release-branch.go1.17] cmd/compile: drop column info when line number saturates
When line number saturates, we can end up getting non-monotonic
position info, because the start of the next line after line=lineMax,col=2
is line=lineMax,col=1.
Instead, if line==lineMax, make the column always 0 (no column info).
If the line number is wrong, having column info probably isn't that helpful.
Fixes #52095
Change-Id: If3d90472691b1f6163654f3505e2cb98467f2383
Reviewed-on: https://go-review.googlesource.com/c/go/+/385795
Trust: Keith Randall <khr@golang.org> Reviewed-by: Than McIntosh <thanm@google.com>
(cherry picked from commit 1de2344af16125ae2fabed226f2fbb40a150238c)
Reviewed-on: https://go-review.googlesource.com/c/go/+/401315 Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Austin Clements <austin@google.com>
Damien Neil [Tue, 12 Apr 2022 20:38:17 +0000 (13:38 -0700)]
[release-branch.go1.17] syscall: check correct group in Faccessat
The Faccessat call checks the user, group, or other permission bits of a
file to see if the calling process can access it. The test to see if the
group permissions should be used was made with the wrong group id, using
the process's group id rather than the file's group id. Fix this to use
the correct group id.
No test since we cannot easily change file permissions when not running
as root and the test is meaningless if running as root.
For #52313
Fixes #52439
Change-Id: I4e2c84754b0af7830b40fd15dedcbc58374d75ee
Reviewed-on: https://go-review.googlesource.com/c/go/+/399539 Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
(cherry picked from commit f66925e854e71e0c54b581885380a490d7afa30c)
Reviewed-on: https://go-review.googlesource.com/c/go/+/401078
Auto-Submit: Tatiana Bradley <tatiana@golang.org>
Run-TryBot: Tatiana Bradley <tatiana@golang.org>
Run-TryBot: Damien Neil <dneil@google.com>
Auto-Submit: Damien Neil <dneil@google.com> Reviewed-by: Tatiana Bradley <tatiana@golang.org>
Ian Lance Taylor [Fri, 15 Apr 2022 20:46:00 +0000 (13:46 -0700)]
[release-branch.go1.17] runtime: don't block preemption signal in new M's or ensureSigM
No test because we already have a test in the syscall package.
The issue reports 1 failure per 100,000 iterations, which is rare enough
that our builders won't catch the problem.
For #52226
Fixes #52374
Change-Id: I17633ff6cf676b6d575356186dce42cdacad0746
Reviewed-on: https://go-review.googlesource.com/c/go/+/400315
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
(cherry picked from commit e3982660a73b04a87c08215cb5aaa16d816ea573)
Reviewed-on: https://go-review.googlesource.com/c/go/+/400317 Reviewed-by: Austin Clements <austin@google.com>
Bryan C. Mills [Thu, 31 Mar 2022 20:51:32 +0000 (16:51 -0400)]
[release-branch.go1.17] syscall: relax output check in TestGroupCleanupUserNamespace
“If you have a procedure with ten parameters, you probably missed some.”
― attr. Alan J. Perlis
I argue that the same is true for hard-coded special cases.
In TestGroupCleanupUserNamespace, instead of a curated list of strings
observed in the wild we now check for a prefix, as was done for
TestGroupCleanup in CL 24670.
Updates #52088.
Fixes #52148.
Change-Id: I59c5b0c048113e306996c0f8247e09c714d2423a
Reviewed-on: https://go-review.googlesource.com/c/go/+/397316
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
(cherry picked from commit 434b2a5d0dbdfdce6327beb06ca03c02b3fd2785)
Reviewed-on: https://go-review.googlesource.com/c/go/+/398235 Reviewed-by: Ian Lance Taylor <iant@google.com>
Damien Neil [Thu, 5 Aug 2021 18:32:43 +0000 (11:32 -0700)]
[release-branch.go1.17] sync: remove TestWaitGroupMisuse2 and TestWaitGroupMisuse3
These tests are inherently nondeterministic: They exercise a racy
code path for up to one million iterations, and require that an
error occur at least once.
TestWaitGroupMisuse2 in particular is an ongoing source of trybot
flakiness.
Updates #38163.
Fixes #52306.
Change-Id: Ibbbda2c998c915333487ad262d3df6829de01c2b
Reviewed-on: https://go-review.googlesource.com/c/go/+/340249
Trust: Damien Neil <dneil@google.com>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
(cherry picked from commit 011fd002457da0823da5f06b099fcf6e21444b00)
Reviewed-on: https://go-review.googlesource.com/c/go/+/399821
Run-TryBot: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Damien Neil <dneil@google.com>
Cherry Mui [Wed, 16 Mar 2022 17:07:57 +0000 (13:07 -0400)]
[release-branch.go1.17] cmd/link: mark unexported methods for plugins
When plugin is used, we already mark all exported methods
reachable. However, when the plugin and the host program share
a common package, an unexported method could also be reachable
from both the plugin and the host via interfaces. We need to mark
them as well.
Fixes #51736.
Updates #51621.
Change-Id: I1a70d3f96b66b803f2d0ab14d00ed0df276ea500
Reviewed-on: https://go-review.googlesource.com/c/go/+/393365
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com>
(cherry picked from commit 91631bc7e0131367eb051b581cf34573399ac592)
Reviewed-on: https://go-review.googlesource.com/c/go/+/397484
Russ Cox [Wed, 12 Jan 2022 22:22:09 +0000 (17:22 -0500)]
[release-branch.go1.17] runtime: fix net poll races
The netpoll code was written long ago, when the
only multiprocessors that Go ran on were x86.
It assumed that an atomic store would trigger a
full memory barrier and then used that barrier
to order otherwise racy access to a handful of fields,
including pollDesc.closing.
On ARM64, this code has finally failed, because
the atomic store is on a value completely unrelated
to any of the racily-accessed fields, and the ARMv8
hardware, unlike x86, is clever enough not to do a
full memory barrier for a simple atomic store.
We are seeing a constant background rate of trybot
failures where the net/http tests deadlock - a netpollblock
has clearly happened after the pollDesc has begun to close.
The code that does the racy reads is netpollcheckerr,
which needs to be able to run without acquiring a lock.
This CL fixes the race, without introducing unnecessary
inefficiency or deadlock, by arranging for every updater
of the relevant fields to publish a summary as a single
atomic uint32, and then having netpollcheckerr use a
single atomic load to fetch the relevant bits and then
proceed as before.
For #45211
Fixes #50611
Change-Id: Ib6788c8da4d00b7bda84d55ca3fdffb5a64c1a0a
Reviewed-on: https://go-review.googlesource.com/c/go/+/378234
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Trust: Bryan Mills <bcmills@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
(cherry picked from commit 17b2fb1b656a275906b5071c562439d50a27f167)
Reviewed-on: https://go-review.googlesource.com/c/go/+/392714
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Cherry Mui [Thu, 3 Mar 2022 18:35:44 +0000 (13:35 -0500)]
[release-branch.go1.17] runtime: count spill slot for frame size at finalizer call
The finalizer is called using reflectcall. When register ABI is
used, the finalizer's argument is passed in register(s). But the
frame size calculation does not include the spill slot. When the
argument actually spills, it may clobber the caller's stack frame.
This CL fixes it.
Updates #51457.
Fixes #51458.
Change-Id: Ibcc7507c518ba65c1c5a7759e5cab0ae3fc7efce
Reviewed-on: https://go-review.googlesource.com/c/go/+/389574
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
(cherry picked from commit 58804ea67a28c1d8e37ed548b685bc0c09638886)
Reviewed-on: https://go-review.googlesource.com/c/go/+/389794
Bryan C. Mills [Wed, 23 Feb 2022 16:55:08 +0000 (11:55 -0500)]
[release-branch.go1.17] cmd/go: avoid +incompatible major versions if a go.mod file exists in a subdirectory for that version
Previous versions of the 'go' command would reject a pseudo-version
passed to 'go get' if that pseudo-version had a mismatched major
version and lacked a "+incompatible" suffix. However, they would
erroneously accept a version *with* a "+incompatible" suffix even if
the repo contained a vN/go.mod file for the same major version, and
would generate a "+incompatible" pseudo-version or version if the user
requested a tag, branch, or commit hash.
This change uniformly rejects "vN.…" without "+incompatible", and also
avoids resolving to "vN.…+incompatible", when vN/go.mod exists.
To maintain compatibility with existing go.mod files, it still accepts
"vN.…+incompatible" if the version is requested explicitly as such
and the repo root lacks a go.mod file.
There was an off-by-one error in the time histogram buckets calculation
that caused the linear sub-buckets distances to be off by 2x.
The fix was trivial, but in writing tests I realized there was a much
simpler way to express the calculation for the histogram buckets, and
took the opportunity to do that here. The new bucket calculation also
fixes the bug.
For #50732.
Fixes #50734.
Change-Id: Idae89986de1c415ee4e148f778e0e101ca003ade
Reviewed-on: https://go-review.googlesource.com/c/go/+/380094 Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
(cherry picked from commit 2e9dcb508647dc473a37ecfa244d2bc4a1843ab4)
Reviewed-on: https://go-review.googlesource.com/c/go/+/384621
TryBot-Result: Gopher Robot <gobot@golang.org>
Ian Lance Taylor [Tue, 15 Feb 2022 21:40:49 +0000 (13:40 -0800)]
[release-branch.go1.17] net: increase maximum accepted DNS packet to 1232 bytes
The existing value of 512 bytes as is specified by RFC 1035.
However, the WSL resolver reportedly sends larger packets without
setting the truncation bit, which breaks using the Go resolver.
For 1.18 and backports, just increase the accepted packet size.
This is what GNU glibc does (they use 65536 bytes).
For 1.19 we plan to use EDNS to set the accepted packet size.
That will give us more time to test whether that causes any problems.
No test because I'm not sure how to write one and it wouldn't really
be useful anyhow.
For #6464
For #21160
For #44135
For #51127
For #51153
Fixes #51162
Change-Id: I0243f274a06e010ebb714e138a65386086aecf17
Reviewed-on: https://go-review.googlesource.com/c/go/+/386015
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
(cherry picked from commit 6e82ff83cfbef78aa60706c1a7167a31c30e7ef9)
Reviewed-on: https://go-review.googlesource.com/c/go/+/386035 Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Russ Cox [Wed, 2 Feb 2022 21:41:32 +0000 (16:41 -0500)]
[release-branch.go1.17] regexp/syntax: reject very deeply nested regexps in Parse
The regexp code assumes it can recurse over the structure of
a regexp safely. Go's growable stacks make that reasonable
for all plausible regexps, but implausible ones can reach the
“infinite recursion?” stack limit.
This CL limits the depth of any parsed regexp to 1000.
That is, the depth of the parse tree is required to be ≤ 1000.
Regexps that require deeper parse trees will return ErrInternalError.
A future CL will change the error to ErrInvalidDepth,
but using ErrInternalError for now avoids introducing new API
in point releases when this is backported.
Cherry Mui [Wed, 22 Sep 2021 22:32:45 +0000 (18:32 -0400)]
[release-branch.go1.17] runtime: set vdsoSP to caller's SP consistently
m.vdsoSP should be set to the SP of the caller of nanotime1,
instead of the SP of nanotime1 itself, which matches m.vdsoPC.
Otherwise the unmatched vdsoPC and vdsoSP would make the stack
trace look like recursive.
We already do it correctly on AMD64, 386, and RISCV64. This CL
fixes the rest.
Also incorporate CL 352509, skipping a flaky test.
Updates #47324, #50772.
Fixes #50781.
Change-Id: I98b6fcfbe9fc6bdd28b8fe2a1299b7c505371dd4
Reviewed-on: https://go-review.googlesource.com/c/go/+/337590
Trust: Cherry Mui <cherryyz@google.com>
Trust: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
(cherry picked from commit 217507eb035933bac6c990844f0d71d6000fd339)
Reviewed-on: https://go-review.googlesource.com/c/go/+/380715
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
Cherry Mui [Thu, 16 Dec 2021 19:33:13 +0000 (14:33 -0500)]
[release-branch.go1.17] cmd/link: force eager binding when using plugins on darwin
When building/using plugins on darwin, we need to use flat
namespace so the same symbol from the main executable and the
plugin can be resolved to the same address. Apparently, when using
flat namespace the dynamic linker can hang at forkExec when
resolving a lazy binding. Work around it by forcing early bindings.
Updates #38824.
Fixes #50246.
Change-Id: I983aa0a0960b15bf3f7871382e8231ee244655f4
Reviewed-on: https://go-review.googlesource.com/c/go/+/372798
Trust: Cherry Mui <cherryyz@google.com> Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
(cherry picked from commit c5fee935bbb8f02406eb653cfed550593755a1a4)
Reviewed-on: https://go-review.googlesource.com/c/go/+/373094
Bryan C. Mills [Thu, 13 Jan 2022 20:38:14 +0000 (15:38 -0500)]
[release-branch.go1.17] cmd/go/internal/modfetch: do not short-circuit canonical versions
Since at least CL 121857, the conversion logic in
(*modfetch).codeRepo.Stat has had a short-circuit to use the version
requested by the caller if it successfully resolves and is already
canonical.
However, we should not use that version if it refers to a branch
instead of a tag, because branches (unlike tags) usually do not refer
to a single, stable release: a branch named "v1.0.0" may be for the
development of the v1.0.0 release, or for the development of patches
based on v1.0.0, but only one commit (perhaps at the end of that
branch — but possibly not even written yet!) can be that specific
version.
We already have some logic to prefer tags that are semver-equivalent
to the version requested by the caller. That more general case
suffices for exact equality too — so we can eliminate the
special-case, fixing the bug and (happily!) also somewhat simplifying
the code.
Cherry Mui [Tue, 18 Jan 2022 23:36:00 +0000 (18:36 -0500)]
[release-branch.go1.17] cmd/compile: don't elide extension for LoadReg to FP register on MIPS64
For an extension operation like MOVWreg, if the operand is already
extended, we optimize the second extension out. Usually a LoadReg
of a proper type would come already extended, as a MOVW/MOVWU etc.
instruction does. But for a LoadReg to a floating point register,
the instruction does not do the extension. So we cannot elide the
extension.
Updates #50671.
Fixes #50683.
Change-Id: Id8991df78d5acdecd3fd6138c558428cbd5f6ba3
Reviewed-on: https://go-review.googlesource.com/c/go/+/379236
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
(cherry picked from commit d93ff73ae207763871bee38590242be968b2e743)
Reviewed-on: https://go-review.googlesource.com/c/go/+/379514
Damien Neil [Mon, 4 Oct 2021 17:20:22 +0000 (10:20 -0700)]
[release-branch.go1.17] net/http/internal/testcert: use FIPS-compliant certificate
Upgrade the test certificate from RSA 1024 (not FIPS-approved)
to RSA 2048 (FIPS-approved), allowing tests to pass when
the dev.boringcrypto branch FIPS-only mode is enabled.
For #48674.
Fixes #50586.
Change-Id: I613d2f8d0207bf3683fd0df256bf0167604996c5
Reviewed-on: https://go-review.googlesource.com/c/go/+/353869
Trust: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com> Reviewed-by: Filippo Valsorda <filippo@golang.org>
(cherry picked from commit 90860e0c3110ac5898dfe8e0e0fafd0aea8d979a)
Reviewed-on: https://go-review.googlesource.com/c/go/+/380995
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Michael Anthony Knyszek [Mon, 23 Aug 2021 17:27:40 +0000 (17:27 +0000)]
[release-branch.go1.17] runtime: set iOS addr space to 40 bits with incremental pagealloc
In iOS <14, the address space is strictly limited to 8 GiB, or 33 bits.
As a result, the page allocator also assumes all heap memory lives in
this region. This is especially necessary because the page allocator has
a PROT_NONE mapping proportional to the size of the usable address
space, so this keeps that mapping very small.
However starting with iOS 14, this restriction is relaxed, and mmap may
start returning addresses outside of the <14 range. Today this means
that in iOS 14 and later, users experience an error in the page
allocator when a heap arena is mapped outside of the old range.
This change increases the ios/arm64 heapAddrBits to 40 while
simultaneously making ios/arm64 use the 64-bit pagealloc implementation
(with reservations and incremental mapping) to accommodate both iOS
versions <14 and 14+.
Once iOS <14 is deprecated, we can remove these exceptions and treat
ios/arm64 like any other arm64 platform.
This change also makes the BaseChunkIdx expression a little bit easier
to read, while we're here.
For #46860.
Fixes #48116.
Change-Id: I13865f799777739109585f14f1cc49d6d57e096b
Reviewed-on: https://go-review.googlesource.com/c/go/+/344401
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Austin Clements <austin@google.com>
(cherry picked from commit af368da0b137116faba81ca249a8d964297e6e45)
Reviewed-on: https://go-review.googlesource.com/c/go/+/369737
Cherry Mui [Tue, 30 Nov 2021 23:58:53 +0000 (18:58 -0500)]
[release-branch.go1.17] runtime/race: rebuild darwin syso to work around macOS 12 malloc reserved address
On macOS 12 a new malloc implementation (nano) is used by default,
and apparently it reserves address range
0x600000000000-0x600020000000, which conflicts with the address
range that TSAN uses for Go. Work around the issue by changing the
address range slightly.
The actual change is made on LLVM at https://reviews.llvm.org/D114825 .
This CL includes syso's built with the patch applied.
The syso in 1.17 was identical to the syso before the equivalent fix
on the main branch, so the back-ported syso is identical to the fixed
syso on the main branch.
Fixes #50073.
Updates #49138.
Change-Id: I7b367d6e042b0db39a691c71601c98e4f8728a70
Reviewed-on: https://go-review.googlesource.com/c/go/+/367916
Trust: Cherry Mui <cherryyz@google.com> Reviewed-by: Austin Clements <austin@google.com>
(cherry picked from commit 5f6552018d1ec920c3ca3d459691528f48363c3c)
Reviewed-on: https://go-review.googlesource.com/c/go/+/370697
hanpro [Fri, 5 Nov 2021 01:47:54 +0000 (09:47 +0800)]
[release-branch.go1.17] cmd/compile: avoid adding LECall to the entry block when has opendefers
The openDeferRecord always insert vardef/varlive pairs into the entry block, it may destroy the mem chain when LECall's args are writing into the same block. So create a new block before that happens.
Fixes #49413
Change-Id: Ibda6c4a45d960dd412a641f5e02276f663c80785
Reviewed-on: https://go-review.googlesource.com/c/go/+/361410
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Alberto Donizetti <alb.donizetti@gmail.com>
Trust: Than McIntosh <thanm@google.com> Reviewed-by: David Chase <drchase@google.com>
(cherry picked from commit 4f083c7dcf6ace3e837b337e10cf2f4e3160677e)
Reviewed-on: https://go-review.googlesource.com/c/go/+/362054 Reviewed-by: Keith Randall <khr@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Keith Randall [Fri, 12 Nov 2021 00:58:23 +0000 (19:58 -0500)]
[release-branch.go1.17] reflect: keep pointer in aggregate-typed args live in Call
When register ABI is used, reflect.Value.Call prepares the call
arguments in a memory representation of the argument registers.
It has special handling to keep the pointers in arguments live.
Currently, this handles pointer-typed arguments. But when an
argument is an aggregate-type that contains pointers and passed
in registers, it currently doesn't keep the pointers live. Do
so in this CL.
Fixes #49961
Change-Id: I9264a8767e2a2c48573f6047144759b845dcf480
Reviewed-on: https://go-review.googlesource.com/c/go/+/369098
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
Russ Cox [Wed, 8 Dec 2021 23:06:41 +0000 (18:06 -0500)]
[release-branch.go1.17] syscall: avoid writing to p when Pipe(p) fails
Generally speaking Go functions make no guarantees
about what has happened to result parameters on error,
and Pipe is no exception: callers should avoid looking at
p if Pipe returns an error.
However, we had a bug in which ForkExec was using the
content of p after a failed Pipe, and others may too.
As a robustness fix, make Pipe avoid writing to p on failure.
Updates #50057
Change-Id: Ie8955025dbd20702fabadc9bbe1d1a5ac0f36305
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1291271 Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/370535
Trust: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org> Reviewed-by: Alex Rakoczy <alex@golang.org>
Russ Cox [Wed, 8 Dec 2021 23:05:11 +0000 (18:05 -0500)]
[release-branch.go1.17] syscall: fix ForkLock spurious close(0) on pipe failure
Pipe (and therefore forkLockPipe) does not make any guarantees
about the state of p after a failed Pipe(p). Avoid that assumption
and the too-clever goto, so that we don't accidentally Close a real fd
if the failed pipe leaves p[0] or p[1] set >= 0.
Updates #50057
Fixes CVE-2021-44717
Change-Id: Iff8e19a6efbba0c73cc8b13ecfae381c87600bb4
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1291270 Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/370534
Trust: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Alex Rakoczy <alex@golang.org>
Cuong Manh Le [Fri, 5 Nov 2021 13:30:38 +0000 (20:30 +0700)]
[release-branch.go1.17] cmd/compile: only update source type when processing struct/array
This is backport of CL 3651594, with the test from CL 360057.
CL 360057 fixed missing update source type in storeArgOrLoad. However,
we should only update the type when processing struct/array. If we
update the type right before calling storeArgOrLoad, we may generate a
value with invalid type, e.g, OpStructSelect with non-struct type.
Fixes #49392
Change-Id: Ib7e10f72f818880f550aae5c9f653db463ce29b0
Reviewed-on: https://go-review.googlesource.com/c/go/+/361594
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/361596
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
Pull in approved backports to golang.org/x/net/http2:
85e122b net/http2: Fix handling of expect continue 1dc0aec http2: don't count aborted streams as active in tests e973a42 ipv6: OpenBSD does not appear to support multicast loopback 9592dd5 http2: avoid busy loop when ResponseHeaderTimeout is set 94fb2bc http2: avoid spurious RoundTrip error when server closes and resets stream e108c19 http2: close conns after use when req.Close is set
By doing:
$ go get -d golang.org/x/net@internal-branch.go1.17-vendor
go: upgraded golang.org/x/net v0.0.0-20211101194204-95aca89e93de => v0.0.0-20211201233630-85e122b1a9b3
$ go mod tidy
$ go mod vendor
$ go generate -run=bundle std
Change-Id: Ia8f432bd3ea77d24e63d46c8ed2ac8d275406b52
Reviewed-on: https://go-review.googlesource.com/c/go/+/368574
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Damien Neil [Mon, 8 Nov 2021 19:23:27 +0000 (11:23 -0800)]
[release-branch.go1.17] net/http: do not cancel request context on response body read
When sending a Request with a non-context deadline, we create a
context with a timeout. This context is canceled when closing the
response body, and also if a read from the response body returns
an error (including io.EOF).
Cancelling the context in Response.Body.Read interferes with the
HTTP/2 client cleaning up after a request is completed, and is
unnecessary: The user should always close the body, the impact
from not canceling the context is minor (the context timer leaks
until it fires).
Fixes #49559.
For #49366.
Change-Id: Ieaed866116916261d9079f71d8fea7a7b303b8fb
Reviewed-on: https://go-review.googlesource.com/c/go/+/361919
Trust: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit 76fbd6167364fb98e3ebe946cfc16b5b84d4240e)
Reviewed-on: https://go-review.googlesource.com/c/go/+/368085 Reviewed-by: Michael Knyszek <mknyszek@google.com>
Jason A. Donenfeld [Mon, 29 Nov 2021 20:07:04 +0000 (15:07 -0500)]
[release-branch.go1.17] runtime: keep //go:cgo_unsafe_args arguments alive to prevent GC
When syscall's DLL.FindProc calls into syscall_getprocaddress with a
byte slice pointer, we need to keep those bytes alive. Otherwise the GC
will collect the allocation, and we wind up calling `GetProcAddress` on
garbage, which showed up as various flakes in the builders. It turns out
that this problem extends to many uses of //go:cgo_unsafe_args
throughout, on all platforms. So this patch fixes the issue by keeping
non-integer pointer arguments alive through their invocation in
//go:cgo_unsafe_args functions.
Fixes #49868.
Updates #49731.
Change-Id: I93e4fbc2e8e210cb3fc53149708758bb33f2f9c7
Reviewed-on: https://go-review.googlesource.com/c/go/+/368355
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
zhouguangyuan [Tue, 2 Nov 2021 15:17:21 +0000 (23:17 +0800)]
[release-branch.go1.17] time: fix looking for zone offset when date is close to a zone transition
The old implement passed start - 1 or end in func lookup to adjust the offset.But if the time is close to the last zoneTrans, like the issue, testcase and comment, the "start" from lookup will be omega. It can't be adjusted correctly.
Fixes #49407
Change-Id: Ibaf82dc4db6d5dd3279796f003d2b19c38a26341
Reviewed-on: https://go-review.googlesource.com/c/go/+/360616
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Robert Findley <rfindley@google.com>
(cherry picked from commit 90462dfc3aa99649de90bb587af56a9cb0214665)
Reviewed-on: https://go-review.googlesource.com/c/go/+/361955
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Dan Scales [Wed, 8 Sep 2021 15:41:54 +0000 (08:41 -0700)]
[release-branch.go1.17] cmd/compile: fix case where init info of OAS node is dropped
When an OAS node is converted to an OSELRECV2 node in tcSelect(), the
possible DCL node in the Init field was being dropped, since a
completely new node was being created and the Init field was not set. I
don't expect n.Init() to be set for the ORECV case, but the code now
deals with that too.
Fixed bug in both tcSelect() and transformSelect().
Cherry-picked from https://go-review.googlesource.com/c/go/+/348569
Fixes #49511
Change-Id: Id5b736daa8e90afda88aaa3769dde801db294c0d
Reviewed-on: https://go-review.googlesource.com/c/go/+/363664
Trust: Dan Scales <danscales@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Jason A. Donenfeld [Thu, 4 Nov 2021 23:10:31 +0000 (00:10 +0100)]
[release-branch.go1.17] runtime: use correct constant when computing nsec remainder
A code comment on amd64 for windows and plan9 contained a snippet for
splitting apart the sec and nsec components of a unix timestamp, with
produced assembly below, which was then cleaned up by hand. When arm64
was ported, that code snippet in the comment went through the compiler
to produce some code that was then pasted and cleaned up. Unfortunately,
the comment had a typo in it, containing 8 zeros instead of 9.
This resulted in the constant used in the assembly being wrong, spotted
by @bufflig's eagle eyes. So, this commit fixes the comment on all three
platforms, and the assembly on windows/arm64.
Updates #48072.
Fixes #49369.
Change-Id: I786fe89147328b0d25544f52c927ddfdb9f6f1cf
Reviewed-on: https://go-review.googlesource.com/c/go/+/361474
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by: Patrik Nyblom <pnyb@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-on: https://go-review.googlesource.com/c/go/+/361476
Jason A. Donenfeld [Wed, 3 Nov 2021 17:19:04 +0000 (18:19 +0100)]
[release-branch.go1.17] runtime: on windows, read nanotime with one instruction or issue barrier
On 64-bit, this is more efficient, and on ARM64, this prevents the time
from moving backwards due to the weaker memory model. On ARM32 due to
the weaker memory model, we issue a memory barrier.
Updates #48072.
Updates #49369.
Change-Id: If4695716c3039d8af14e14808af217f5c99fc93a
Reviewed-on: https://go-review.googlesource.com/c/go/+/361057
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/361475 Reviewed-by: Patrik Nyblom <pnyb@google.com>
Keith Randall [Sat, 23 Oct 2021 17:16:41 +0000 (10:16 -0700)]
[release-branch.go1.17] cmd/compile: fix fuse pass to do CFG surgery correctly
removePred and removeArg do different things. removePred moves the last
predecessor to index k, whereas removeArg slides all the args k or
greater down by 1 index.
Kind of unfortunate different behavior in things named similarly.
Fixes #49129
Change-Id: I9ae409bdac744e713f4c121f948e43db6fdc8542
Reviewed-on: https://go-review.googlesource.com/c/go/+/358117
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
(cherry picked from commit 8dbf3e9393400d72d313e5616c88873e07692c70)
Reviewed-on: https://go-review.googlesource.com/c/go/+/358118 Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Bryan C. Mills [Mon, 22 Nov 2021 19:01:26 +0000 (14:01 -0500)]
[release-branch.go1.17] cmd/go: forward the MallocNanoZone variable to script tests
For #49138
Updates #49723
Fixes #49729
Change-Id: Ia93130fdc042a1e2107be95cccd7e7eeaa909a87
Reviewed-on: https://go-review.googlesource.com/c/go/+/366254
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
(cherry picked from commit 189b4a2f428be7264db76e5275c96d98b847383b)
Reviewed-on: https://go-review.googlesource.com/c/go/+/366257
TryBot-Result: Go Bot <gobot@golang.org>
Cherry Mui [Tue, 2 Nov 2021 22:30:08 +0000 (18:30 -0400)]
[release-branch.go1.17] cmd/link: don't use label symbol for absolute address relocations on ARM64 PE
On ARM64 PE, when external linking, the PE relocation does not
have an explicit addend, and instead has the addend encoded in
the instruction or data. An instruction (e.g. ADRP, ADD) has
limited width for the addend, so when the addend is large we use
a label symbol, which points to the middle of the original target
symbol, and a smaller addend. But for an absolute address
relocation in the data section, we have the full width to encode
the addend and we should not use the label symbol. Also, since we
do not adjust the addend in the data, using the label symbol will
actually make it point to the wrong address. E.g for an R_ADDR
relocation targeting x+0x123456, we should emit 0x123456 in the
data with an IMAGE_REL_ARM64_ADDR64 relocation pointing to x,
whereas the current code emits 0x123456 in the data with an
IMAGE_REL_ARM64_ADDR64 relocation pointing to the label symbol
x+1MB, so it will actually be resolved to x+0x223456. This CL
fixes this.
Fixes #49479
Change-Id: I64e02b56f1d792f8c20ca61b78623ef5c3e34d7e
Reviewed-on: https://go-review.googlesource.com/c/go/+/360895
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com>
(cherry picked from commit 988efd58197205060ace508d29984fbab6eb3840)
Reviewed-on: https://go-review.googlesource.com/c/go/+/363014
Run-TryBot: Carlos Amedee <carlos@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
Than McIntosh [Thu, 4 Nov 2021 13:00:47 +0000 (09:00 -0400)]
[release-branch.go1.17] go1.17.3
Change-Id: Iaf0b58846a9641525f43f4dc64962c13c0c7e8e3
Reviewed-on: https://go-review.googlesource.com/c/go/+/361200
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
[release-branch.go1.17] archive/zip: don't panic on (*Reader).Open
Previously, opening a zip with (*Reader).Open could result in a panic if
the zip contained a file whose name was exclusively made up of slash
characters or ".." path elements.
Open could also panic if passed the empty string directly as an argument.
Now, any files in the zip whose name could not be made valid for
fs.FS.Open will be skipped, and no longer added to the fs.FS file list,
although they are still accessible through (*Reader).File.
Note that it was already the case that a file could be accessible from
(*Reader).Open with a name different from the one in (*Reader).File, as
the former is the cleaned name, while the latter is the original one.
Finally, made the actual panic site robust as a defense-in-depth measure.