Bryan C. Mills [Wed, 23 Feb 2022 16:55:08 +0000 (11:55 -0500)]
[release-branch.go1.16] 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 #50733.
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/+/384620
Ian Lance Taylor [Tue, 15 Feb 2022 21:40:49 +0000 (13:40 -0800)]
[release-branch.go1.16] 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 #51161
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/+/386034 Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Russ Cox [Wed, 2 Feb 2022 21:41:32 +0000 (16:41 -0500)]
[release-branch.go1.16] 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.
Fixes #51112.
Fixes #51117.
Change-Id: I97d2cd82195946eb43a4ea8561f5b95f91fb14c5
Reviewed-on: https://go-review.googlesource.com/c/go/+/384616
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-on: https://go-review.googlesource.com/c/go/+/384855
Cherry Mui [Wed, 22 Sep 2021 22:32:45 +0000 (18:32 -0400)]
[release-branch.go1.16] 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 #50780.
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/+/380716
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.16] 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 #50245.
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/+/373095
Bryan C. Mills [Thu, 13 Jan 2022 20:38:14 +0000 (15:38 -0500)]
[release-branch.go1.16] 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.16] 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 #50682.
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/+/379515
Daniel S. Fava [Fri, 12 Feb 2021 08:54:50 +0000 (09:54 +0100)]
[release-branch.go1.16] testing/race: fixing intermittent test failure
Test NoRaceMutexPureHappensBefore in runtime/race/testdata/mutex_test.go
expects the second spawned goroutine to run after the first. The test
attempts to force this scheduling with a 10 millisecond wait. Following
a suggestion by Bryan Mills, we force this scheduling using a shared
variable whose access take place within the existing mutex.
Fixes #50832.
Updates #35745.
Change-Id: Ib23ec51492ecfeed4752e020401dd25755a669ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/291292 Reviewed-by: Bryan C. Mills <bcmills@google.com> Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
(cherry picked from commit aaed6cbced238030053df4e54f676a1d59df89d7)
Reviewed-on: https://go-review.googlesource.com/c/go/+/381034
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Damien Neil [Mon, 4 Oct 2021 17:20:22 +0000 (10:20 -0700)]
[release-branch.go1.16] net/http/internal: 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 #50585.
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/+/380997
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Tobias Klauser [Tue, 8 Jun 2021 13:33:54 +0000 (15:33 +0200)]
[release-branch.go1.16] testing: drop unusual characters from TempDir directory name
Only use safe characters of the test name for the os.MkdirTemp pattern.
This currently includes the alphanumeric characters and ASCII
punctuation characters known not to interact with globs.
For #46624
Fixes #50645
Change-Id: I402c34775b943fed9b97963c52f79245cc16dc1d
Reviewed-on: https://go-review.googlesource.com/c/go/+/326010
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
(cherry picked from commit 97cee43c93cfccded197cd281f0a5885cdb605b4)
Reviewed-on: https://go-review.googlesource.com/c/go/+/378914
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Michael Anthony Knyszek [Mon, 23 Aug 2021 17:27:40 +0000 (17:27 +0000)]
[release-branch.go1.16] 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 #48115.
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/+/369736
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Cherry Mui [Tue, 30 Nov 2021 23:58:53 +0000 (18:58 -0500)]
[release-branch.go1.16] 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.16 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 #50072.
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/+/370698
hanpro [Fri, 5 Nov 2021 01:47:54 +0000 (09:47 +0800)]
[release-branch.go1.16] 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 #49412
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/+/362055 Reviewed-by: Keith Randall <khr@golang.org>
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Cherry Mui [Fri, 25 Jun 2021 19:58:38 +0000 (15:58 -0400)]
[release-branch.go1.16] runtime/race: use race build tag on syso_test.go
All other test files in the runtime/race package have race build
tag, except syso_test.go. The test is only relevant if the race
detector is supported. So apply the build tag.
Updates #46931.
Fixes #50194.
Change-Id: Icdb94214d3821b4ccf61133412ef39b4d7cc7691
Reviewed-on: https://go-review.googlesource.com/c/go/+/331050
Trust: Cherry Mui <cherryyz@google.com> Reviewed-by: Elias Naur <mail@eliasnaur.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
(cherry picked from commit ed01ceaf4838cd67fd802df481769fa9ae9d0440)
Reviewed-on: https://go-review.googlesource.com/c/go/+/372218 Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Russ Cox [Wed, 8 Dec 2021 23:06:41 +0000 (18:06 -0500)]
[release-branch.go1.16] 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/+/370515
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>
Russ Cox [Wed, 8 Dec 2021 23:05:11 +0000 (18:05 -0500)]
[release-branch.go1.16] 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/+/370514
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.16] 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 #49391
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/+/361597
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
Pull in approved backports to golang.org/x/net/http2:
64539c1 http2: don't count aborted streams as active in tests e677a40 ipv6: OpenBSD does not appear to support multicast loopback d8ae719 net/http2: Fix handling of expect continue cc2f99c http2: avoid busy loop when ResponseHeaderTimeout is set 5533dda http2: avoid spurious RoundTrip error when server closes and resets stream 26ec667 http2: close conns after use when req.Close is set
Change-Id: I73261b189f84cf1919a79129ec36a1c187723133
Reviewed-on: https://go-review.googlesource.com/c/go/+/368594
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.16] 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).
For #49366.
Fixes #49558.
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/+/368084 Reviewed-by: Michael Knyszek <mknyszek@google.com>
Jason A. Donenfeld [Mon, 29 Nov 2021 20:07:04 +0000 (15:07 -0500)]
[release-branch.go1.16] 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 #49867.
Updates #49731.
Change-Id: I93e4fbc2e8e210cb3fc53149708758bb33f2f9c7
Reviewed-on: https://go-review.googlesource.com/c/go/+/368356
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.16] 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 #49406
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/+/361954 Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Bryan C. Mills [Mon, 22 Nov 2021 19:01:26 +0000 (14:01 -0500)]
[release-branch.go1.16] cmd/go: forward the MallocNanoZone variable to script tests
For #49138
Updates #49723
Fixes #49728
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/+/366258
TryBot-Result: Go Bot <gobot@golang.org>
Than McIntosh [Thu, 4 Nov 2021 12:59:03 +0000 (08:59 -0400)]
[release-branch.go1.16] go1.16.10
Change-Id: I872971806a723e6add42bb78f91a8ef8586f3d58
Reviewed-on: https://go-review.googlesource.com/c/go/+/361199
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.16] 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.
Pull in approved backports to golang.org/x/net/http2:
d8c3cde set ContentLength to -1 for HEAD response with no Content-Length 7b24c0a set Response.ContentLength to 0 when headers end stream c4031f5 don't abort half-closed streams on server connection close 2f744fa on write errors, close ClientConn before returning from RoundTrip 275be3f deflake TestTransportReqBodyAfterResponse_200 d26011a close the Request's Body when aborting a stream e5dd05d return unexpected eof on empty response with non-zero content length 640e170 don't rely on system TCP buffer sizes in TestServer_MaxQueuedControlFrames 198b78c detect write-blocked PING frames 20ed279 avoid race in TestTransportReqBodyAfterResponse_403. d585ef0 avoid clientConnPool panic when NewClientConn fails d06dfc7 avoid extra GetConn trace call 1760f31 refactor request write flow 6e87631 remove PingTimeout from TestTransportPingWhenReading b843c7d fix Transport connection pool TOCTOU max concurrent stream bug ab1d67c shut down idle Transport connections after protocol errors 3741e47 remove check for read-after-close of request bodies 2df4c53 fix race in DATA frame padding refund d7eefc9 avoid blocking while holding ClientConn.mu 78e8d65 fix off-by-one error in client check for max concurrent streams 828651b close request body after early RoundTrip failures 59c0c25 limit client initial MAX_CONCURRENT_STREAMS 524fcad make Transport not reuse conns after a stream protocol error 0fe5f8a accept zero-length block fragments in HEADERS frames 0e5043f close the request body if needed bb4ce86 reduce frameScratchBuffer caching aggressiveness 3112343 also set "http/1.1" ALPN in ConfigureServer 63939f4 switch to ASCII equivalents of string functions 54161af use (*tls.Dialer).DialContext in dialTLS 75b906f discard DATA frames with higher stream IDs during graceful shutdown 1dfe517 rework Ping test to rely less on timing
By doing:
$ go get -d golang.org/x/net@internal-branch.go1.16-vendor
go get: upgraded golang.org/x/net v0.0.0-20210901185431-d2e9a4ea682f => v0.0.0-20211101194150-d8c3cde3c676
$ go mod tidy
$ go mod vendor
$ go generate -run=bundle std
Fixes #49076.
Fixes #48822.
Fixes #48649.
Change-Id: Ie17f327eef2b6e6a9a1ac7635c5c4daef792e893
Reviewed-on: https://go-review.googlesource.com/c/go/+/359774
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Damien Neil <dneil@google.com>
Roland Shoemaker [Thu, 14 Oct 2021 20:02:01 +0000 (13:02 -0700)]
[release-branch.go1.16] debug/macho: fail on invalid dynamic symbol table command
Fail out when loading a file that contains a dynamic symbol table
command that indicates a larger number of symbols than exist in the
loaded symbol table.
Thanks to Burak Çarıkçı - Yunus Yıldırım (CT-Zer0 Crypttech) for
reporting this issue.
Updates #48990
Fixes #48991
Fixes CVE-2021-41771
Change-Id: Ic3d6e6529241afcc959544b326b21b663262bad5
Reviewed-on: https://go-review.googlesource.com/c/go/+/355990 Reviewed-by: Julie Qiu <julie@golang.org> Reviewed-by: Katie Hockman <katie@golang.org> Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Katie Hockman <katie@golang.org>
(cherry picked from commit 61536ec03063b4951163bd09609c86d82631fa27)
Reviewed-on: https://go-review.googlesource.com/c/go/+/359454 Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Richard Musiol [Sun, 24 Oct 2021 10:28:18 +0000 (12:28 +0200)]
[release-branch.go1.16] cmd/link: increase reserved space for passing env on wasm
On wasm, the wasm_exec.js helper passes the command line arguments and
environment variables via a reserved space in the wasm linear memory.
Increase this reserved space from 4096 to 8192 bytes so more environment
variables can fit into the limit.
Later, after https://golang.org/cl/350737 landed, we can switch to the
WASI interface for getting the arguments and environment. This would
remove the limit entirely.
Updates #49011.
Fixes #49153.
Change-Id: I48a6e952a97d33404ed692c98e9b49c5cd6b269b
Reviewed-on: https://go-review.googlesource.com/c/go/+/358194
Trust: Richard Musiol <neelance@gmail.com>
Run-TryBot: Richard Musiol <neelance@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
(cherry picked from commit 252324e879e32f948d885f787decf8af06f82be9)
Reviewed-on: https://go-review.googlesource.com/c/go/+/359400
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Michael Pratt [Thu, 14 Oct 2021 22:18:49 +0000 (18:18 -0400)]
[release-branch.go1.16] runtime: consistently access pollDesc r/w Gs with atomics
Both netpollblock and netpollunblock read gpp using a non-atomic load.
When consuming a ready event, netpollblock clears gpp using a non-atomic
store, thus skipping a barrier.
Thus on systems with weak memory ordering, a sequence like so this is
possible:
i.e., without a happens-before edge between (2) and (3), netpollunblock
may read the stale value of gpp.
Switch these access to use atomic loads and stores in order to create
these edges.
For ease of future maintainance, I've simply changed rg and wg to always
be accessed atomically, though I don't believe pollOpen or pollClose
require atomics today.
For #48925
Fixes #49009
Change-Id: I903ea667eea320277610b4f969129935731520c3
Reviewed-on: https://go-review.googlesource.com/c/go/+/355952
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: David Chase <drchase@google.com>
(cherry picked from commit 1b072b3ed56c18619587354f499fcda5279718a2)
Reviewed-on: https://go-review.googlesource.com/c/go/+/356370
Keith Randall [Mon, 20 Sep 2021 04:09:57 +0000 (21:09 -0700)]
[release-branch.go1.16] cmd/compile: ensure constant shift amounts are in range for arm
Ensure constant shift amounts are in the range [0-31]. When shift amounts
are out of range, bad things happen. Shift amounts out of range occur
when lowering 64-bit shifts (we take an in-range shift s in [0-63] and
calculate s-32 and 32-s, both of which might be out of [0-31]).
The constant shift operations themselves still work, but their shift
amounts get copied unmolested to operations like ORshiftLL which use only
the low 5 bits. That changes an operation like <<100 which unconditionally
produces 0, to <<4, which doesn't.
Fixes #48478
Change-Id: I87363ef2b4ceaf3b2e316426064626efdfbb8ee3
Reviewed-on: https://go-review.googlesource.com/c/go/+/350969
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
(cherry picked from commit eff27e858b771bf5e0b5e7e836827c7d2941e6d4)
Reviewed-on: https://go-review.googlesource.com/c/go/+/351070 Reviewed-by: Austin Clements <austin@google.com>
Michael Knyszek [Thu, 2 Sep 2021 20:51:59 +0000 (16:51 -0400)]
[release-branch.go1.16] misc/wasm, cmd/link: do not let command line args overwrite global data
On Wasm, wasm_exec.js puts command line arguments at the beginning
of the linear memory (following the "zero page"). Currently there
is no limit for this, and a very long command line can overwrite
the program's data section. Prevent this by limiting the command
line to 4096 bytes, and in the linker ensuring the data section
starts at a high enough address (8192).
(Arguably our address assignment on Wasm is a bit confusing. This
is the minimum fix I can come up with.)
Thanks to Ben Lubar for reporting this issue.
Change by Cherry Mui <cherryyz@google.com>.
For #48797
Fixes #48799
Fixes CVE-2021-38297
Change-Id: I0f50fbb2a5b6d0d047e3c134a88988d9133e4ab3
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1205933 Reviewed-by: Roland Shoemaker <bracewell@google.com> Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/354591
Trust: Michael Knyszek <mknyszek@google.com> Reviewed-by: Heschi Kreinick <heschi@google.com>
Ian Lance Taylor [Fri, 17 Sep 2021 19:27:23 +0000 (12:27 -0700)]
[release-branch.go1.16] text/template: initialize template before locking it
For #39807
For #48436
Fixes #48443
Change-Id: I75f82fd8738dd2f11f0c69b1230e1be1abc36024
Reviewed-on: https://go-review.googlesource.com/c/go/+/350730
Trust: Ian Lance Taylor <iant@golang.org>
Trust: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
(cherry picked from commit ba1c52d7d77724de4407572bd02421c36df3d78a)
Reviewed-on: https://go-review.googlesource.com/c/go/+/351116
Ian Lance Taylor [Fri, 20 Aug 2021 23:55:04 +0000 (16:55 -0700)]
[release-branch.go1.16] runtime: in adjustTimers back up as far as necessary
When the adjustTimers function removed a timer it assumed it was
sufficient to continue the heap traversal at that position.
However, in some cases a timer will be moved to an earlier
position in the heap. If that timer is timerModifiedEarlier,
that can leave timerModifiedEarliest not correctly representing
the earlier such timer.
Fix the problem by restarting the heap traversal at the earliest
changed position.
For #47762
Fixes #47858
Change-Id: I152bbe62793ee40a680baf49967bcb89b1f94764
Reviewed-on: https://go-review.googlesource.com/c/go/+/343882
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 2da3375e9b4980e368a8641f54cc53c4af4d1a12)
Reviewed-on: https://go-review.googlesource.com/c/go/+/350000
Than McIntosh [Thu, 9 Sep 2021 14:05:55 +0000 (10:05 -0400)]
[release-branch.go1.16] go1.16.8
Change-Id: I1926e1506e56fd0484bec71f7b43cee62e41b5b5
Reviewed-on: https://go-review.googlesource.com/c/go/+/348812
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
Trust: Than McIntosh <thanm@google.com>
Ian Lance Taylor [Mon, 3 May 2021 23:32:52 +0000 (16:32 -0700)]
[release-branch.go1.16] text/template: add lock for Template.tmpl to fix data race
This adds a new lock protecting "tmpl".
This is a copy of https://golang.org/cl/257817 by Andreas Fleig,
updated for current tip, and updated to start running the
html/template TestEscapeRace test.
Thanks to @bep for providing the test case.
For #39807
Fixes #47042
Change-Id: Ic8874484290283a49116812eeaffb8608346dc70
Reviewed-on: https://go-review.googlesource.com/c/go/+/316669
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
(cherry picked from commit 496d7c691481966fd6ea806205aa025698a172af)
Reviewed-on: https://go-review.googlesource.com/c/go/+/348580 Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Damien Neil [Wed, 1 Sep 2021 19:59:25 +0000 (12:59 -0700)]
[release-branch.go1.16] all: update golang.org/x/net to pull in CL 346890
For #47691.
Change-Id: I6650fdfc78786fc47a54167bf2f9061422bbb343
Reviewed-on: https://go-review.googlesource.com/c/go/+/347031
Trust: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
Roland Shoemaker [Wed, 18 Aug 2021 18:49:29 +0000 (11:49 -0700)]
[release-branch.go1.16] archive/zip: prevent preallocation check from overflowing
If the indicated directory size in the archive header is so large that
subtracting it from the archive size overflows a uint64, the check that
the indicated number of files in the archive can be effectively
bypassed. Prevent this from happening by checking that the indicated
directory size is less than the size of the archive.
Thanks to the OSS-Fuzz project for discovering this issue and to
Emmanuel Odeke for reporting it.
Fixes #47985
Updates #47801
Fixes CVE-2021-39293
Change-Id: Ifade26b98a40f3b37398ca86bd5252d12394dd24
Reviewed-on: https://go-review.googlesource.com/c/go/+/343434
Trust: Roland Shoemaker <roland@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
(cherry picked from commit bacbc33439b124ffd7392c91a5f5d96eca8c0c0b)
Reviewed-on: https://go-review.googlesource.com/c/go/+/345409 Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
Trust: Cherry Mui <cherryyz@google.com>
Michael Pratt [Thu, 12 Aug 2021 21:17:51 +0000 (17:17 -0400)]
[release-branch.go1.16] runtime: drop SIGPROF while in ARM < 7 kernel 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 20a620fd9f7bc35739c1af3602d53808d0430814)
Reviewed-on: https://go-review.googlesource.com/c/go/+/341853
Than McIntosh [Fri, 19 Feb 2021 15:34:55 +0000 (10:34 -0500)]
[release-branch.go1.16] go/internal/gccgoimporter: fix up gccgo installation 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 0f66fb7b856b02497cf801ce72d80f375f53358b)
Reviewed-on: https://go-review.googlesource.com/c/go/+/340952
David Chase [Wed, 4 Aug 2021 19:11:35 +0000 (19:11 +0000)]
[release-branch.go1.16] go1.16.7
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>
Derek Parker [Thu, 17 Jun 2021 20:22:40 +0000 (20:22 +0000)]
[release-branch.go1.16] runtime: fix crash during VDSO calls on PowerPC
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:
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:
https://github.com/golang/go/commit/f4ca3c1e0a2066ca4f7bd6203866d282ed34acf2
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 16e82be454cbf41299e6a055d54d489ca4612ee0)
Reviewed-on: https://go-review.googlesource.com/c/go/+/334410
Run-TryBot: Cherry Mui <cherryyz@google.com>
Yasuhiro Matsumoto [Tue, 22 Jun 2021 16:02:33 +0000 (01:02 +0900)]
[release-branch.go1.16] cmd/go: use path.Dir instead of filepath.Dir 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 835d86a17ebf32a3cb081f66119c74363dbd8825)
Reviewed-on: https://go-review.googlesource.com/c/go/+/332329 Reviewed-by: Jay Conrod <jayconrod@google.com>
Cherry Zhang [Fri, 28 Jun 2019 13:30:36 +0000 (09:30 -0400)]
[release-branch.go1.16] cmd/compile: mark R16, R17 clobbered for non-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 11b4aee05bfe83513cf08f83091e5aef8b33e766)
Reviewed-on: https://go-review.googlesource.com/c/go/+/331029
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Than McIntosh [Thu, 15 Jul 2021 20:29:36 +0000 (16:29 -0400)]
[release-branch.go1.16] cmd/{compile,link}: fix bug in map.zero handling
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 49402bee36fd3d5cee9f4b2d2e1e8560ead0203b)
Reviewed-on: https://go-review.googlesource.com/c/go/+/335629
Roland Shoemaker [Fri, 12 Mar 2021 17:51:50 +0000 (09:51 -0800)]
[release-branch.go1.16] cmd/go/internal/load: always set IsImportCycle 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 cdd08e615a9b92742b21a94443720b6d70452510)
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>
Damien Neil [Wed, 7 Jul 2021 23:34:34 +0000 (16:34 -0700)]
[release-branch.go1.16] net/http/httputil: close incoming ReverseProxy 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 b7a85e0003cedb1b48a1fd3ae5b746ec6330102e)
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>
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 bfbb288574841f2db2499a580d7bf985a5df4556)
Reviewed-on: https://go-review.googlesource.com/c/go/+/338649
Ian Lance Taylor [Thu, 22 Jul 2021 02:57:56 +0000 (19:57 -0700)]
[release-branch.go1.16] runtime: don't clear timerModifiedEarliest if 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 798ec73519a7226d6d436e42498a54aed23b8468)
Reviewed-on: https://go-review.googlesource.com/c/go/+/336689
Roland Shoemaker [Wed, 9 Jun 2021 18:31:27 +0000 (11:31 -0700)]
[release-branch.go1.16] crypto/tls: test key type when casting
When casting the certificate public key in generateClientKeyExchange,
check the type is appropriate. This prevents a panic when a server
agrees to a RSA based key exchange, but then sends an ECDSA (or
other) certificate.
Roland Shoemaker [Fri, 2 Jul 2021 17:25:49 +0000 (10:25 -0700)]
[release-branch.go1.16] net: filter bad names from Lookup functions instead of hard failing
Instead of hard failing on a single bad record, filter the bad records
and return anything valid. This only applies to the methods which can
return multiple records, LookupMX, LookupNS, LookupSRV, and LookupAddr.
When bad results are filtered out, also return an error, indicating
that this filtering has happened.
Updates #46241
Updates #46979
Fixes #46999
Change-Id: I6493e0002beaf89f5a9795333a93605abd30d171
Reviewed-on: https://go-review.googlesource.com/c/go/+/332549
Trust: Roland Shoemaker <roland@golang.org> Reviewed-by: Filippo Valsorda <filippo@golang.org>
(cherry picked from commit 296ddf2a936a30866303a64d49bc0e3e034730a8)
Reviewed-on: https://go-review.googlesource.com/c/go/+/333330
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Damien Neil [Fri, 12 Mar 2021 21:53:11 +0000 (13:53 -0800)]
[release-branch.go1.16] net/http: fix ResponseWriter.ReadFrom with short reads
CL 249238 changes ResponseWriter.ReadFrom to probe the source with
a single read of sniffLen bytes before writing the response header.
If the source returns less than sniffLen bytes without reaching
EOF, this can cause Content-Type and Content-Length detection to
fail.
Fix ResponseWrite.ReadFrom to copy a full sniffLen bytes from
the source as a probe.
Drop the explicit call to w.WriteHeader; writing the probe will
trigger a WriteHeader call.
Consistently use io.CopyBuffer; ReadFrom has already acquired a
copy buffer, so it may as well use it.
Fixes #44984.
Updates #44953.
Change-Id: Ic49305fb827a2bd7da4764b68d64b797b5157dc0
Reviewed-on: https://go-review.googlesource.com/c/go/+/301449
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 831f9376d8d730b16fb33dfd775618dffe13ce7a)
Reviewed-on: https://go-review.googlesource.com/c/go/+/324971 Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Than McIntosh [Wed, 9 Jun 2021 00:09:49 +0000 (20:09 -0400)]
[release-branch.go1.16] cmd/compile: make map.zero symbol content-addressable
The compiler machinery that generates "map.zero" symbols marks them as
RODATA and DUPOK, which is problematic when a given application has
multiple map zero symbols (from different packages) with varying
sizes: the dupok path in the loader assumes that if two symbols have
the same name, it is safe to pick any of the versions. In the case of
map.zero, the link needs to select the largest symbol, not an
arbitrary sym.
To fix this problem, mark map.zero symbols as content-addressable,
since the loader's content addressability processing path already
supports selection of the larger symbol in cases where there are dups.
Fixes #46657.
Change-Id: Iabd2feef01d448670ba795c7eaddc48c191ea276
Reviewed-on: https://go-review.googlesource.com/c/go/+/326211
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 aa5540cd82170f82c6fe11511e12de96aa58cbc1)
Reviewed-on: https://go-review.googlesource.com/c/go/+/326212
Run-TryBot: Cherry Mui <cherryyz@google.com>
David Chase [Thu, 3 Jun 2021 16:08:00 +0000 (16:08 +0000)]
[release-branch.go1.16] go1.16.5
Change-Id: Ibe47050481a01ec434f87db31048981e21fba1c3
Reviewed-on: https://go-review.googlesource.com/c/go/+/324552
Run-TryBot: David Chase <drchase@google.com>
Trust: David Chase <drchase@google.com> Reviewed-by: Carlos Amedee <carlos@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Roland Shoemaker [Wed, 2 Jun 2021 16:20:22 +0000 (09:20 -0700)]
[release-branch.go1.16] net: don't rely on system hosts in TestCVE202133195
Also don't unnecessarily deref the error return.
Updates #46504
Fixes #46530
Change-Id: I22d14ac76776f8988fa0774bdcb5fcd801ce0185
Reviewed-on: https://go-review.googlesource.com/c/go/+/324190
Trust: David Chase <drchase@google.com>
Trust: Damien Neil <dneil@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Damien Neil <dneil@google.com>
(cherry picked from commit dd7ba3ba2c860c40be6d70b63d4a678449cae80f)
Reviewed-on: https://go-review.googlesource.com/c/go/+/324332
Run-TryBot: Damien Neil <dneil@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Bryan C. Mills [Thu, 13 May 2021 13:48:40 +0000 (09:48 -0400)]
[release-branch.go1.16] cmd/go: error out of 'go mod tidy' if the go version is newer than supported
This backports the test from CL 319669, but — because of extensive
changes to the module loader during the Go 1.17 cycle — the
implementation is entirely different. (This implementation is based on
the addGoStmt function present in init.go in the 1.16 branch.)
Fixes #46144
Updates #46142
Change-Id: Ib7a0a159e53cbe476be6aa9a050add10cc750dec
Reviewed-on: https://go-review.googlesource.com/c/go/+/319671
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
[release-branch.go1.16] cmd/go: use a real Go version in the go.mod files in TestScript/mod_readonly
For some reason, the go.mod file added to this test in CL 147281 lists
'go 1.20' instead of the version that was actually current when the
go.mod file was added.
That causes the test's behavior to change under lazy loading, because
1.20 is above the threshold to trigger lazy-loading invariants (1.17).
This backports CL 314049 to Go 1.16 in order to fix a spurious test
failure in a subsequent change.
For #46144
Updates #46142
Updates #36460
Change-Id: I92400996cb051ab30e99bfffafd91ff32a1e7087
Reviewed-on: https://go-review.googlesource.com/c/go/+/314049
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Michael Matloob <matloob@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-on: https://go-review.googlesource.com/c/go/+/319670 Reviewed-by: Jay Conrod <jayconrod@google.com>
Jay Conrod [Mon, 10 May 2021 22:10:18 +0000 (18:10 -0400)]
[release-branch.go1.16] cmd/go: in 'go mod download' without args, don't save module zip sums
'go mod download' without arguments is frequently used to populate the
module cache. It tends to fetch a lot of extra files (for modules in
the build list that aren't needed to build packages in the main
module). It's annoying when sums are written for these extra files.
'go mod download mod@version' will still write sums for specific
modules in the build list. 'go mod download all' still has the
previous behavior.
For now, all invocations of 'go mod download' still update go.mod and
go.sum with changes needed to load the build list (1.15 behavior).
Fixes #46214
Change-Id: I9e17d18a7466ac7271a0e1a2b663f6b3cb168c97
Reviewed-on: https://go-review.googlesource.com/c/go/+/318629
Trust: Jay Conrod <jayconrod@google.com> Reviewed-by: Bryan C. Mills <bcmills@google.com>
(cherry picked from commit 4fb10b2118cb16445f2d089f79beb3d32db3db12)
Reviewed-on: https://go-review.googlesource.com/c/go/+/321892
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
[release-branch.go1.16] cmd/link/internal: fix use of DynlinkingGo with ppc64le trampolines
When creating programs with large text sections on ppc64le,
trampolines are needed for calls that are too far; however
they are not created if the code is generated such that the TOC
register r2 is initialized and maintained in the code because
then the external linker can create the trampolines. Previously
the function DynlinkingGo was used to determine this but in the
case where plugins are used, this could return true even though
r2 is not valid.
To fix this problem I've added a new function r2Valid which returns
true when the build options indicate that the r2 is
initialized and maintained. Because of the ways that
DynlinkingGo is used I wanted to maintain its previous
behavior.
Fixes #45927
Change-Id: I6d902eba6ad41757aa6474948b79acdbd479cb38
Reviewed-on: https://go-review.googlesource.com/c/go/+/315289
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com> Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
(cherry picked from commit 9ed736ac2a99aa2e7ef7d8bed3b01ca8b20a6f80)
Reviewed-on: https://go-review.googlesource.com/c/go/+/316750
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
Michael Fraenkel [Thu, 13 May 2021 15:41:45 +0000 (09:41 -0600)]
[release-branch.go1.16] net/http: prevent infinite wait during TestMissingStatusNoPanic
If the client request never makes it to the server, the outstanding
accept is never broken. Change the test to always close the listening
socket when the client request completes.
Updates #45358
Change-Id: I744a91dfa11704e7e528163d7669c394e90456dc
Reviewed-on: https://go-review.googlesource.com/c/go/+/319275
Trust: Heschi Kreinick <heschi@google.com> Reviewed-by: Bryan C. Mills <bcmills@google.com>
(cherry picked from commit c0a7ecfae775a9d50d338e8123fac32a5d04308c)
Reviewed-on: https://go-review.googlesource.com/c/go/+/320190 Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Roland Shoemaker [Tue, 11 May 2021 18:31:31 +0000 (11:31 -0700)]
[release-branch.go1.16] archive/zip: only preallocate File slice if reasonably sized
Since the number of files in the EOCD record isn't validated, it isn't
safe to preallocate Reader.Files using that field. A malformed archive
can indicate it contains up to 1 << 128 - 1 files. We can still safely
preallocate the slice by checking if the specified number of files in
the archive is reasonable, given the size of the archive.
Thanks to the OSS-Fuzz project for discovering this issue and to
Emmanuel Odeke for reporting it.
Updates #46242
Fixes #46397
Fixes CVE-2021-33196
Change-Id: I3c76d8eec178468b380d87fdb4a3f2cb06f0ee76
Reviewed-on: https://go-review.googlesource.com/c/go/+/318909
Trust: Roland Shoemaker <roland@golang.org>
Trust: Katie Hockman <katie@golang.org>
Trust: Joe Tsai <thebrokentoaster@gmail.com>
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Katie Hockman <katie@golang.org> Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
(cherry picked from commit 74242baa4136c7a9132a8ccd9881354442788c8c)
Reviewed-on: https://go-review.googlesource.com/c/go/+/322909 Reviewed-by: Filippo Valsorda <filippo@golang.org>
Roland Shoemaker [Thu, 27 May 2021 17:40:06 +0000 (10:40 -0700)]
[release-branch.go1.16] net: verify results from Lookup* are valid domain names
For the methods LookupCNAME, LookupSRV, LookupMX, LookupNS, and
LookupAddr check that the returned domain names are in fact valid DNS
names using the existing isDomainName function.
Thanks to Philipp Jeitner and Haya Shulman from Fraunhofer SIT for
reporting this issue.
Updates #46241
Fixes #46357
Fixes CVE-2021-33195
Change-Id: I47a4f58c031cb752f732e88bbdae7f819f0af4f3
Reviewed-on: https://go-review.googlesource.com/c/go/+/323131
Trust: Roland Shoemaker <roland@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Filippo Valsorda <filippo@golang.org> Reviewed-by: Katie Hockman <katie@golang.org>
(cherry picked from commit cdcd02842da7c004efd023881e3719105209c908)
Reviewed-on: https://go-review.googlesource.com/c/go/+/323270
[release-branch.go1.16] runtime/pprof: skip tests for AIX
Most of the time, the pprof tests are passing, except
for the builder. The reason is still unknown but I'd rather release
the builder to avoid missing other more important bugs.
Andrew G. Morgan [Sat, 27 Mar 2021 02:27:22 +0000 (19:27 -0700)]
[release-branch.go1.16] syscall: syscall.AllThreadsSyscall signal handling fixes
The runtime support for syscall.AllThreadsSyscall() functions had
some corner case deadlock issues when signal handling was in use.
This was observed in at least 3 build test failures on ppc64 and
amd64 architecture CGO_ENABLED=0 builds over the last few months.
The fixes involve more controlled handling of signals while the
AllThreads mechanism is being executed. Further details are
discussed in bug #44193.
The all-threads syscall support is new in go1.16, so earlier
releases are not affected by this bug.
Fixes #45307
Change-Id: I01ba8508a6e1bb2d872751f50da86dd07911a41d
Reviewed-on: https://go-review.googlesource.com/c/go/+/305149 Reviewed-by: Michael Pratt <mpratt@google.com>
Trust: Michael Pratt <mpratt@google.com>
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
(cherry picked from commit 7e97e4e8ccdba9677f31ab9380802cd7613f62c5)
Reviewed-on: https://go-review.googlesource.com/c/go/+/316869
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Paul E. Murphy [Thu, 15 Apr 2021 18:41:01 +0000 (13:41 -0500)]
[release-branch.go1.16] cmd/compile: fix ANDI/SRWI merge on ppc64
The shift amount should be masked to avoid rotation values
beyond the numer of bits. In this case, if the shift amount
is 0, it should rotate 0, not 32.
Fixes #45636
Change-Id: I1e764497a39d0ec128e29af42352b70c70b2ecc5
Reviewed-on: https://go-review.googlesource.com/c/go/+/310569
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com> Reviewed-by: Carlos Eduardo Seo <carlos.seo@linaro.org>
Trust: Carlos Eduardo Seo <carlos.seo@linaro.org>
(cherry picked from commit c8fb0ec5a005289e9dd890b746e543b38bbd9528)
Reviewed-on: https://go-review.googlesource.com/c/go/+/311378 Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
Michael Pratt [Fri, 9 Apr 2021 21:01:45 +0000 (17:01 -0400)]
[release-branch.go1.16] runtime: non-strict InlTreeIndex lookup in expandFinalInlineFrame
This is a follow-up to golang.org/cl/301369, which made the same change
in Frames.Next. The same logic applies here: a profile stack may have
been truncated at an invalid PC provided by cgoTraceback.
expandFinalInlineFrame will then try to lookup the inline tree and
crash.
The same fix applies as well: upon encountering a bad PC, simply leave
it as-is and move on.
For #44971
For #45480
Fixes #45482
Change-Id: I2823c67a1f3425466b05384cc6d30f5fc8ee6ddc
Reviewed-on: https://go-review.googlesource.com/c/go/+/309109 Reviewed-by: Michael Knyszek <mknyszek@google.com>
Trust: Michael Pratt <mpratt@google.com>
(cherry picked from commit aad13cbb749d1e6c085ff0556d306de1a2d5d063)
Reviewed-on: https://go-review.googlesource.com/c/go/+/309551
Run-TryBot: Michael Pratt <mpratt@google.com> Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Ian Lance Taylor [Mon, 19 Apr 2021 20:51:53 +0000 (13:51 -0700)]
[release-branch.go1.16] archive/zip: only return directory once via io/fs.FS
While we're here fix the ModTime value for directories.
For #43872
For #45345
Fixes #45347
Change-Id: I155e6517713ef6a9482b9431f1167a44337c6ad2
Reviewed-on: https://go-review.googlesource.com/c/go/+/311530
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Jeremy Faller <jeremy@golang.org>
(cherry picked from commit 87e4dcd446df2ab1985ef61ce15da329493248a1)
Reviewed-on: https://go-review.googlesource.com/c/go/+/315249
Trust: Jeremy Faller <jeremy@golang.org>
Ian Lance Taylor [Mon, 5 Apr 2021 19:10:21 +0000 (12:10 -0700)]
[release-branch.go1.16] time: use offset and isDST when caching zone from extend string
If the current time is computed from extend string
and the zone file contains multiple zones with the
same name, the lookup by name might find incorrect
zone.
This happens for example with the slim Europe/Dublin
time zone file in the embedded zip. This zone file
has last transition in 1996 and rest is covered by
extend string.
tzset returns IST as the zone name to use, but there
are two records with IST name. Lookup by name finds
the wrong one. We need to check offset and isDST too.
In case we can't find an existing zone, we allocate
a new zone so that we use correct offset and isDST.
I have renamed zone variable to zones as it shadowed
the zone type that we need to allocate the cached zone.
Backport note: this change also incorporates portions of
CL 264077.
For #45370
Fixes #45385
Change-Id: If7a0cccc1908e27f0509bf422d824133133250fc
Reviewed-on: https://go-review.googlesource.com/c/go/+/307211
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>