Jay Conrod [Thu, 4 Mar 2021 16:50:31 +0000 (11:50 -0500)]
[release-branch.go1.15] cmd/go: don't report missing std import errors for tidy and vendor
'go mod tidy' and 'go mod vendor' normally report errors when a
package can't be imported, even if the import appears in a file that
wouldn't be compiled by the current version of Go. These errors are
common for packages introduced in higher versions of Go, like "embed"
in 1.16.
This change causes 'go mod tidy' and 'go mod vendor' to ignore
missing package errors if the import path appears to come from the
standard library because it lacks a dot in the first path element.
NOTE: This change is not a clean cherry-pick of CL 298749 because
parts of modload were substantially rewritten after 1.15.
Fixes #44792
Updates #27063
Change-Id: I61d6443e77ab95fd8c0d1514f57ef4c8885a77cc
Reviewed-on: https://go-review.googlesource.com/c/go/+/298749
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com> Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
(cherry picked from commit 56d52e661114be60fb1893b034ac0c5976b622af)
Reviewed-on: https://go-review.googlesource.com/c/go/+/298950
Michael Fraenkel [Thu, 3 Dec 2020 00:07:27 +0000 (17:07 -0700)]
[release-branch.go1.15] net/http: add connections back that haven't been canceled
Issue #41600 fixed the issue when a second request canceled a connection
while the first request was still in roundTrip.
This uncovered a second issue where a request was being canceled (in
roundtrip) but the connection was put back into the idle pool for a
subsequent request.
The fix is the similar except its now in readLoop instead of roundTrip.
A persistent connection is only added back if it successfully removed
the cancel function; otherwise we know the roundTrip has started
cancelRequest.
Fixes #42935.
Updates #42942.
Change-Id: Ia56add20880ccd0c1ab812d380d8628e45f6f44c
Reviewed-on: https://go-review.googlesource.com/c/go/+/274973
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Trust: Damien Neil <dneil@google.com> Reviewed-by: Damien Neil <dneil@google.com>
(cherry picked from commit 854a2f8e01a554d8052445563863775406a04b71)
Reviewed-on: https://go-review.googlesource.com/c/go/+/297910
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Matthew Dempsky [Sat, 27 Feb 2021 17:41:19 +0000 (09:41 -0800)]
[release-branch.go1.15] cmd/compile: fix escape analysis of heap-allocated results
One of escape analysis's responsibilities is to summarize whether/how
each function parameter flows to the heap so we can correctly
incorporate those flows into callers' escape analysis data flow
graphs.
As an optimization, we separately record when parameters flow to
result parameters, so that we can more precisely analyze parameter
flows based on how the results are used at the call site. However, if
a named result parameter itself needs to be heap allocated, this
optimization isn't safe and the parameter needs to be recorded as
flowing to heap rather than flowing to result.
Escape analysis used to get this correct because it conservatively
rewalked the data-flow graph multiple times. So even though it would
incorrectly record the result parameter flow, it would separately find
a flow to the heap. However, CL 196811 (specifically, case 3)
optimized the walking logic to reduce unnecessary rewalks causing us
to stop finding the extra heap flow.
This CL fixes the issue by correcting location.leakTo to be sensitive
to sink.escapes and not record result-flows when the result parameter
escapes to the heap.
Fixes #44658.
Change-Id: I48742ed35a6cab591094e2d23a439e205bd65c50
Reviewed-on: https://go-review.googlesource.com/c/go/+/297289
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-on: https://go-review.googlesource.com/c/go/+/297291
First, the tzdata code permits timezone offsets up to 24 * 7, although
the POSIX TZ parsing does not. The tzdata code uses this to specify a
day of week in some cases.
Second, we incorrectly rejected a negative time offset for when a time
zone change comes into effect.
For #44385
Fixes #44617
Change-Id: I5f2efc1d385e9bfa974a0de3fa81e7a94b827602
Reviewed-on: https://go-review.googlesource.com/c/go/+/296392
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
(cherry picked from commit d9fd38e68ba00a51c2c7363150688d0e7687ef84)
Reviewed-on: https://go-review.googlesource.com/c/go/+/297229
Jason A. Donenfeld [Tue, 23 Feb 2021 12:29:40 +0000 (13:29 +0100)]
[release-branch.go1.15] syscall: do not overflow key memory in GetQueuedCompletionStatus
The third argument to GetQueuedCompletionStatus is a pointer to a
uintptr, not a uint32. Users of this functions have therefore been
corrupting their memory every time they used it. Either that memory
corruption was silent (dangerous), or their programs didn't work so they
chose a different API to use.
This fixes the problem by passing through an intermediate buffer.
Updates #44538.
Fixes #44592.
Change-Id: Icacd71f705b36e41e52bd8c4d74898559a27522f
Reviewed-on: https://go-review.googlesource.com/c/go/+/296151
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
Jason A. Donenfeld [Mon, 30 Nov 2020 09:41:46 +0000 (10:41 +0100)]
[release-branch.go1.15] cmd/compile: do not assume TST and TEQ set V on arm
These replacement rules assume that TST and TEQ set V. But TST and
TEQ do not set V. This is a problem because instructions like LT are
actually checking for N!=V. But with TST and TEQ not setting V, LT
doesn't do anything meaningful. It's possible to construct trivial
miscompilations from this, such as:
package main
var x = [4]int32{-0x7fffffff, 0x7fffffff, 2, 4}
func main() {
if x[0] > x[1] {
panic("fail 1")
}
if x[2]&x[3] < 0 {
panic("fail 2") // Fails here
}
}
That first comparison sets V, via the CMP that subtracts the values
causing the overflow. Then the second comparison operation thinks that
it uses the result of TST, when it actually uses the V from CMP.
Before this fix:
TST R0, R1
BLT loc_6C164
After this fix:
TST R0, R1
BMI loc_6C164
The BMI instruction checks the N flag, which TST sets. This commit
fixes the issue by using [LG][TE]noov instead of vanilla [LG][TE], and
also adds a test case for the direct issue.
Updates #42876.
Fixes #42930.
Change-Id: I13c62c88d18574247ad002b671b38d2d0b0fc6fa
Reviewed-on: https://go-review.googlesource.com/c/go/+/282432
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
Wei Fu [Sun, 24 Jan 2021 10:21:06 +0000 (18:21 +0800)]
[release-branch.go1.15] internal/poll: netpollcheckerr before sendfile
In net/http package, the ServeContent/ServeFile doesn't check the I/O
timeout error from chunkWriter or *net.TCPConn, which means that both
HTTP status and headers might be missing when WriteTimeout happens. If
the poll.SendFile() doesn't check the *poll.FD state before sending
data, the client will only receive the response body with status and
report "malformed http response/status code".
This patch is to enable netpollcheckerr before sendfile, which should
align with normal *poll.FD.Write() and Splice().
For #43822
Fixes #44294
Change-Id: I32517e3f261bab883a58b577b813ef189214b954
Reviewed-on: https://go-review.googlesource.com/c/go/+/285914 Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
(cherry picked from commit f0d23c9dbb2142b975fa8fb13a57213d0c15bdd1)
Reviewed-on: https://go-review.googlesource.com/c/go/+/296530
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Ian Lance Taylor [Mon, 15 Feb 2021 01:14:41 +0000 (17:14 -0800)]
[release-branch.go1.15] internal/poll: if copy_file_range returns 0, assume it failed
On current Linux kernels copy_file_range does not correctly handle
files in certain special file systems, such as /proc. For those file
systems it fails to copy any data and returns zero. This breaks Go's
io.Copy for those files.
Fix the problem by assuming that if copy_file_range returns 0 the
first time it is called on a file, that that file is not supported.
In that case fall back to just using read. This will force an extra
system call when using io.Copy to copy a zero-sized normal file,
but at least it will work correctly.
For #36817
For #44272
Fixes #44273
Change-Id: I02e81872cb70fda0ce5485e2ea712f219132e614
Reviewed-on: https://go-review.googlesource.com/c/go/+/291989
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
(cherry picked from commit 30641e36aa5b547eee48565caa3078b0a2e7c185)
Reviewed-on: https://go-review.googlesource.com/c/go/+/292289
Carlos Amedee [Thu, 4 Feb 2021 16:17:11 +0000 (11:17 -0500)]
[release-branch.go1.15] go1.15.8
Change-Id: Ic8824cabbc8ae62360e0cda4b7c5604db7d405f3
Reviewed-on: https://go-review.googlesource.com/c/go/+/289694
Run-TryBot: Carlos Amedee <carlos@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Alexander Rakoczy <alex@golang.org>
Trust: Alexander Rakoczy <alex@golang.org>
Trust: Carlos Amedee <carlos@golang.org>
Elias Naur [Fri, 25 Dec 2020 10:14:11 +0000 (11:14 +0100)]
[release-branch.go1.15] runtime/cgo: fix Android build with NDK 22
Fixes #43406
Change-Id: I7d2b70098a4ba4dcb325fb0be076043789b86135
Reviewed-on: https://go-review.googlesource.com/c/go/+/280312
Run-TryBot: Elias Naur <mail@eliasnaur.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Elias Naur <mail@eliasnaur.com>
(cherry picked from commit 1d78139128d6d839d7da0aeb10b3e51b6c7c0749)
Reviewed-on: https://go-review.googlesource.com/c/go/+/289149
Ian Lance Taylor [Wed, 20 Jan 2021 05:30:36 +0000 (21:30 -0800)]
[release-branch.go1.15] runtime: don't adjust timer pp field in timerWaiting status
Before this CL, the following sequence was possible:
* GC scavenger starts and sets up scavenge.timer
* GC calls readyForScavenger, but sysmon is sleeping
* program calls runtime.GOMAXPROCS to shrink number of processors
* procresize destroys a P, the one that scavenge.timer is on
* (*pp).destroy calls moveTimers, which gets to the scavenger timer
* scavenger timer is timerWaiting, and moveTimers clears t.pp
* sysmon wakes up and calls wakeScavenger
* wakeScavengers calls stopTimer on scavenger.timer, still timerWaiting
* stopTimer calls deltimer which loads t.pp, which is still nil
* stopTimer tries to increment deletedTimers on nil t.pp, and crashes
The point of vulnerability is the time that t.pp is set to nil by
moveTimers and the time that t.pp is set to non-nil by moveTimers,
which is a few instructions at most. So it's not likely and in
particular is quite unlikely on x86. But with a more relaxed memory
model the area of vulnerability can be somewhat larger. This appears
to tbe the cause of two builder failures in a few months on linux-mips.
This CL fixes the problem by making moveTimers change the status from
timerWaiting to timerMoving while t.pp is clear. That will cause
deltimer to wait until the status is back to timerWaiting, at which
point t.pp has been set again.
For #43712
Fixes #43833
Change-Id: I66838319ecfbf15be66c1fac88d9bd40e2295852
Reviewed-on: https://go-review.googlesource.com/c/go/+/284775
Trust: Ian Lance Taylor <iant@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Michael Pratt <mpratt@google.com>
(cherry picked from commit d2d155d1ae8c704a37f42fd3ebb1f3846f78e4d4)
Reviewed-on: https://go-review.googlesource.com/c/go/+/287092
Run-TryBot: Carlos Amedee <carlos@golang.org>
For very large object files, this artificial array isn't large enough
(that is, there are more than 1048576 relocs to read), so update the
code to use a larger artifical array size.
Fixes #43214.
Updates #41621.
Change-Id: Ic047c8aef4f8a3839f2e7e3594bce652ebd6bd5b
Reviewed-on: https://go-review.googlesource.com/c/go/+/278492
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com> Reviewed-by: Jeremy Faller <jeremy@golang.org>
Trust: Than McIntosh <thanm@google.com>
(cherry picked from commit f4e7a6b905ce60448e506a3f6578d01b60602cdd)
Reviewed-on: https://go-review.googlesource.com/c/go/+/278673
The resource symbol may have been copied to the mmap'd
output buffer. If so, certain conditions can cause that
mmap'd output buffer to be munmap'd before we get a chance
to use it. To avoid any issues we copy the data to the heap
when the resource symbol exists.
Fixes #42384
Change-Id: I32ef5420802d7313a3d965b8badfbcfb9f0fba4a
GitHub-Last-Rev: 7b0f43011d06083ee3e871e48a87847636f738f9
GitHub-Pull-Request: golang/go#42427
Reviewed-on: https://go-review.googlesource.com/c/go/+/268018
Run-TryBot: Carlos Amedee <carlos@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com> Reviewed-by: Than McIntosh <thanm@google.com>
Trust: Carlos Amedee <carlos@golang.org>
Jay Conrod [Fri, 22 Jan 2021 19:27:24 +0000 (14:27 -0500)]
[release-branch.go1.15] cmd/go: don't lookup the path for CC when invoking cgo
Previously, if CC was a path without separators (like gcc or clang),
we'd look it up in PATH in cmd/go using internal/execabs.LookPath,
then pass the resolved path to cgo in CC.
This caused a regression: if the directory in PATH containing CC has a
space, cgo splits it and interprets it as multiple arguments.
With this change, cmd/go no longer resolves CC before invoking
cgo. cgo does the path lookup on each invocation. This reverts the
security fix CL 284780, but that was redundant with the addition of
internal/execabs (CL 955304), which still protects us.
NOTE: This CL includes a related test fix from CL 286292.
Fixes #43860
Change-Id: I65d91a1e303856df8653881eb6e2e75a3bf95c49
Reviewed-on: https://go-review.googlesource.com/c/go/+/285873
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
(cherry picked from commit a2cef9b544708ecae983ed8836ee2425a28aab68)
Reviewed-on: https://go-review.googlesource.com/c/go/+/285954
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Updates bundled http2 to x/net git rev 16c2bbf55 for:
http2: send a nil error if we cancel a delayed body write
https://golang.org/cl/288013
http2: wait until the request body has been written
https://golang.org/cl/288012
Created by:
go mod edit -replace=golang.org/x/net=golang.org/x/net@release-branch.go1.15-bundle
GOFLAGS='-mod=mod' go generate -run=bundle std
go mod edit -dropreplace=golang.org/x/net
go get -d golang.org/x/net@release-branch.go1.15
go mod tidy
go mod vendor
Fixes golang/go#42539
Change-Id: I299c6d4a67ebc036e45c978e4d03cba73717b363
Reviewed-on: https://go-review.googlesource.com/c/go/+/288112
Trust: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Jay Conrod [Fri, 22 Jan 2021 21:59:16 +0000 (16:59 -0500)]
[release-branch.go1.15] cmd/go: fix get_update_unknown_protocol test
This test needs to run in GOPATH mode. It broke when a go.mod file was
added to github.com/golang/example. This change sets GO111MODULE=off,
which matches master since CL 255051.
Fixes #43861
Change-Id: I9ea109a99509fac3185756a0f0d852a84c677bf5
Reviewed-on: https://go-review.googlesource.com/c/go/+/285956
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
Keith Randall [Thu, 7 Jan 2021 22:57:53 +0000 (14:57 -0800)]
[release-branch.go1.15] cmd/compile: don't short-circuit copies whose source is volatile
Current optimization: When we copy a->b and then b->c, we might as well
copy a->c instead of b->c (then b might be dead and go away).
*Except* if a is a volatile location (might be clobbered by a call).
In that case, we really do want to copy a immediately, because there
might be a call before we can do the a->c copy.
User calls can't happen in between, because the rule matches up the
memory states. But calls inserted for memory barriers, particularly
runtime.typedmemmove, can.
(I guess we could introduce a register-calling-convention version
of runtime.typedmemmove, but that seems a bigger change than this one.)
Fixes #43575
Change-Id: Ifa518bb1a6f3a8dd46c352d4fd54ea9713b3eb1a
Reviewed-on: https://go-review.googlesource.com/c/go/+/282492
Trust: Keith Randall <khr@golang.org>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
(cherry picked from commit 304f769ffc68e64244266b3aadbf91e6738c0064)
Reviewed-on: https://go-review.googlesource.com/c/go/+/282558
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Roland Shoemaker [Fri, 15 Jan 2021 20:14:06 +0000 (12:14 -0800)]
[release-branch.go1.15-security] all: introduce and use internal/execabs
Introduces a wrapper around os/exec, internal/execabs, for use in
all commands. This wrapper prevents exec.LookPath and exec.Command from
running executables in the current directory.
All imports of os/exec in non-test files in cmd/ are replaced with
imports of internal/execabs.
Filippo Valsorda [Fri, 8 Jan 2021 02:56:58 +0000 (03:56 +0100)]
[release-branch.go1.15-security] crypto/elliptic: fix P-224 field reduction
This patch fixes two independent bugs in p224Contract, the function that
performs the final complete reduction in the P-224 field. Incorrect
outputs due to these bugs were observable from a high-level
P224().ScalarMult() call.
The first bug was in the calculation of out3GT. That mask was supposed
to be all ones if the third limb of the value is greater than the third
limb of P (out[3] > 0xffff000). Instead, it was also set if they are
equal. That meant that if the third limb was equal, the value was always
considered greater than or equal to P, even when the three bottom limbs
were all zero. There is exactly one affected value, P - 1, which would
trigger the subtraction by P even if it's lower than P already.
The second bug was more easily hit, and is the one that caused the known
high-level incorrect output: after the conditional subtraction by P, a
potential underflow of the lowest limb was not handled. Any values that
trigger the subtraction by P (values between P and 2^224-1, and P - 1
due to the bug above) but have a zero lowest limb would produce invalid
outputs. Those conditions apply to the intermediate representation
before the subtraction, so they are hard to trace to precise inputs.
This patch also adds a test suite for the P-224 field arithmetic,
including a custom fuzzer that automatically explores potential edge
cases by combining limb values that have various meanings in the code.
contractMatchesBigInt in TestP224Contract finds the second bug in less
than a second without being tailored to it, and could eventually find
the first one too by combining 0, (1 << 28) - 1, and the difference of
(1 << 28) and (1 << 12).
The incorrect P224().ScalarMult() output was found by the
elliptic-curve-differential-fuzzer project running on OSS-Fuzz and
reported by Philippe Antoine (Catena cyber).
Ian Lance Taylor [Sat, 12 Dec 2020 03:10:00 +0000 (19:10 -0800)]
[release-branch.go1.15] doc/go1.15: mention 1.15.3 cgo restriction on empty structs
For #40954
Change-Id: I6a30aed31a16e820817f4ca5c7f591222e922946
Reviewed-on: https://go-review.googlesource.com/c/go/+/277432
Trust: Ian Lance Taylor <iant@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
(cherry picked from commit 129bb1917b4914f0743ec9b4ef0dfb74df39c07d)
Reviewed-on: https://go-review.googlesource.com/c/go/+/278573
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Carlos Amedee [Thu, 3 Dec 2020 16:05:59 +0000 (11:05 -0500)]
[release-branch.go1.15] go1.15.6
Change-Id: I9e050e1463f1bc01c04d1817aef2f81a5aac4d42
Reviewed-on: https://go-review.googlesource.com/c/go/+/275132
Run-TryBot: Carlos Amedee <carlos@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Trust: Carlos Amedee <carlos@golang.org>
MOVLconst must have a properly sign-extended auxint constant.
The bit operations in these rules don't enforce that invariant.
The easiest fix is just to turn on properly typed auxint fields
(which is what fixed this issue at tip).
Fixes #42753
Change-Id: I264245fad45067a6ade65326f7fe681feb5f3739
Reviewed-on: https://go-review.googlesource.com/c/go/+/272028
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
Alessandro Arzilli [Thu, 12 Nov 2020 13:58:46 +0000 (14:58 +0100)]
[release-branch.go1.15] cmd/compile: do not emit an extra debug_line entry for the end of seq addr
Uses DW_LNS_advance_pc directly, instead of calling putpclcdelta
because the latter will create a new debug_line entry for the end of
sequence address.
Updates #42484.
Fixes #42521.
Change-Id: Ib6355605cac101b9bf37a3b4961ab0cee678a839
Reviewed-on: https://go-review.googlesource.com/c/go/+/268937
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/269517
A major rework of the kernel implementation occurred in 5.3. Areas
of the API that weren't clearly defined were clarified and the API
bounds are much more strictly checked than on earlier kernels.
Applications should target the behaviour and requirements of 5.3
kernels.
Rather than attempting to detect the file system for source and
destination files (which means two additional statfs syscalls) and skip
copy_file_range in case of known defects (e.g. CIFS -> CIFS), just
assume copy_file_range to be broken on kernels < 5.3.
Fixes #42550
Change-Id: I3a531296182c1d6e341772cc9d2be5bf83e52575
Reviewed-on: https://go-review.googlesource.com/c/go/+/268338
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
(cherry picked from commit 1c7650aa93bd53b7df0bbb34693fc5a16d9f67af)
Reviewed-on: https://go-review.googlesource.com/c/go/+/269759
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Ian Lance Taylor [Tue, 27 Oct 2020 23:09:40 +0000 (16:09 -0700)]
[release-branch.go1.15] runtime: block signals in needm before allocating M
Otherwise, if a signal occurs just after we allocated the M,
we can deadlock if the signal handler needs to allocate an M
itself.
For #42207
Fixes #42636
Change-Id: I76f44547f419e8b1c14cbf49bf602c6e645d8c14
Reviewed-on: https://go-review.googlesource.com/c/go/+/265759
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
(cherry picked from commit 368c40116434532dc0b53b72fa04788ca6742898)
Reviewed-on: https://go-review.googlesource.com/c/go/+/271847
Ian Lance Taylor [Fri, 13 Nov 2020 19:05:37 +0000 (11:05 -0800)]
[release-branch.go1.15] cmd/go: permit CGO_LDFLAGS to appear in //go:ldflag
For #42565
Fixes #42567
Change-Id: If7cf39905d124dbd54dfac6a53ee38270498efed
Reviewed-on: https://go-review.googlesource.com/c/go/+/269818
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
(cherry picked from commit 782cf560db4c919790fdb476d1bbe18e5ddf5ffd)
Reviewed-on: https://go-review.googlesource.com/c/go/+/270137
Katie Hockman [Tue, 10 Nov 2020 20:54:12 +0000 (15:54 -0500)]
[release-branch.go1.15-security] math/big: fix shift for recursive division
The previous s value could cause a crash
for certain inputs.
Will check in tests and documentation improvements later.
Thanks to the Go Ethereum team and the OSS-Fuzz project for reporting this.
Thanks to Rémy Oudompheng and Robert Griesemer for their help
developing and validating the fix.
Fixes CVE-2020-28362
Change-Id: Ibbf455c4436bcdb07c84a34fa6551fb3422356d3
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/899974 Reviewed-by: Roland Shoemaker <bracewell@google.com> Reviewed-by: Filippo Valsorda <valsorda@google.com>
(cherry picked from commit 28015462c2a83239543dc2bef651e9a5f234b633)
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/901065
Ian Lance Taylor [Tue, 3 Nov 2020 05:31:06 +0000 (21:31 -0800)]
[release-branch.go1.15-security] cmd/go: in cgoflags, permit -DX1, prohibit -Wp,-D,opt
Restrict -D and -U to ASCII C identifiers, but do permit trailing digits.
When using -Wp, prohibit commas in -D values.
Thanks to Imre Rad (https://www.linkedin.com/in/imre-rad-2358749b) for reporting this.
Fixes CVE-2020-28367
Change-Id: Ibfc4dfdd6e6c258e131448e7682610c44eee9492
Reviewed-on: https://go-review.googlesource.com/c/go/+/267277
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/899924 Reviewed-by: Filippo Valsorda <valsorda@google.com>
Ian Lance Taylor [Fri, 6 Nov 2020 17:38:38 +0000 (09:38 -0800)]
[release-branch.go1.15-security] cmd/go, cmd/cgo: don't let bogus symbol set cgo_ldflag
A hand-edited object file can have a symbol name that uses newline and
other normally invalid characters. The cgo tool will generate Go files
containing symbol names, unquoted. That can permit those symbol names
to inject Go code into a cgo-generated file. If that Go code uses the
//go:cgo_ldflag pragma, it can cause the C linker to run arbitrary
code when building a package. If you build an imported package we
permit arbitrary code at run time, but we don't want to permit it at
package build time. This CL prevents this in two ways.
In cgo, reject invalid symbols that contain non-printable or space
characters, or that contain anything that looks like a Go comment.
In the go tool, double check all //go:cgo_ldflag directives in
generated code, to make sure they follow the existing LDFLAG restrictions.
Thanks to Chris Brown and Tempus Ex for reporting this.
Fixes CVE-2020-28366
Change-Id: Ia1ad8f3791ea79612690fa7d26ac451d0f6df7c1
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/895832 Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: Cherry Zhang <cherryyz@google.com>
(cherry picked from commit 6bc814dd2bbfeaafa41d314dd4cc591b575dfbf6)
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/901056 Reviewed-by: Filippo Valsorda <valsorda@google.com> Reviewed-by: Roland Shoemaker <bracewell@google.com>
Alexander Rakoczy [Thu, 5 Nov 2020 18:12:55 +0000 (13:12 -0500)]
[release-branch.go1.15] go1.15.4
Change-Id: Ibcd61e2c7ef7cc6f8509dadea6c3952c5dd7016e
Reviewed-on: https://go-review.googlesource.com/c/go/+/267879
Run-TryBot: Alexander Rakoczy <alex@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Trust: Alexander Rakoczy <alex@golang.org>
go mod edit -replace=golang.org/x/net=golang.org/x/net@release-branch.go1.15-bundle
GOFLAGS='-mod=mod' go generate -run=bundle std
go mod edit -dropreplace=golang.org/x/net
go get -d golang.org/x/net@release-branch.go1.15
go mod tidy
go mod vendor
Updates #39337.
Fixes #42113.
Change-Id: I3ebef4b90c11ad271b7a3031aafd80c423c2c241
Reviewed-on: https://go-review.googlesource.com/c/go/+/266375
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Christopher Hlubek [Mon, 26 Oct 2020 12:44:44 +0000 (13:44 +0100)]
[release-branch.go1.15] time: fix LoadLocationFromTZData with slim tzdata
The extend information of a time zone file with last transition < now
could result in a wrong cached zone because it used the zone of the
last transition.
This could lead to wrong zones in systems with slim zoneinfo.
For #42216
Fixes #42138
Change-Id: I7c57c35b5cfa58482ac7925b5d86618c52f5444d
Reviewed-on: https://go-review.googlesource.com/c/go/+/264939
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
(cherry picked from commit 70e022e4a83dc996ac4f108e811fbc399ad5565b)
Reviewed-on: https://go-review.googlesource.com/c/go/+/266299
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Ian Lance Taylor [Thu, 22 Oct 2020 22:25:00 +0000 (15:25 -0700)]
[release-branch.go1.15] time: support slim tzdata format
Backport of part of https://golang.org/cl/261877 to support the slim
tzdata format. As of tzdata 2020b, the default is to use the slim format.
We need to support that format so that Go installations continue to
work when tzdata is updated.
Relevant part of the CL description:
The reason for the failed tests was that when caching location data, the
extended time format past the end of zone transitions was not
considered. The respective change was introduced in (*Location).lookup
by CL 215539.
For #42138
Change-Id: I37f52a0917b2c6e3957e6b4612c8ef104c736e65
Reviewed-on: https://go-review.googlesource.com/c/go/+/264301
Trust: Ian Lance Taylor <iant@golang.org> Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
The fastest compression mode can pick up a false match for every 2GB
of input data resulting in incorrectly decompressed data.
Since matches are allowed to be up to and including at maxMatchOffset
we must offset the buffer by an additional element to prevent the first
4 bytes to match after an out-of-reach value after shiftOffsets has
been called.
We offset by `maxMatchOffset + 1` so offset 0 in the table will now
fail the `if offset > maxMatchOffset` in all cases.
Updates #41420.
Fixes #41463.
Change-Id: If1fbe01728e132b8a207e3f3f439edd832dcc710
GitHub-Last-Rev: 50fabab0da874c37543b139459a810e12e83cee2
GitHub-Pull-Request: golang/go#41477
Reviewed-on: https://go-review.googlesource.com/c/go/+/255879 Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Joe Tsai <thebrokentoaster@gmail.com>
Trust: Matthew Dempsky <mdempsky@google.com>
(cherry picked from commit ab541a0560408999ac65d12bec2a3057994eda38)
Reviewed-on: https://go-review.googlesource.com/c/go/+/266177
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
Tobias Klauser [Wed, 28 Oct 2020 12:44:53 +0000 (13:44 +0100)]
[release-branch.go1.15] cmd/go/internal/modfetch: drop gopkg.in/russross/blackfriday.v2 from TestCodeRepoVersions
Follow-up for CL 265819.
Given the -pre tag added recently, a new stable version is likely
tagged soon. This would break TestCodeRepoVersions on the longtest
builders again. Since the other test cases in codeRepoVersionsTests
already provide enough coverage, drop gopkg.in/russross/blackfriday.v2
to avoid breaking TestCodeRepoVersions once the release happens.
Updates #28856
Change-Id: If86a637b5e47f59faf9048fc1cbbae6e8f1dcc53
Reviewed-on: https://go-review.googlesource.com/c/go/+/265917
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> 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 421d4e72de802ed65cb38317660654771cfb13e9)
Reviewed-on: https://go-review.googlesource.com/c/go/+/266178
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Keith Randall [Thu, 22 Oct 2020 20:11:16 +0000 (13:11 -0700)]
[release-branch.go1.15] cmd/compile: fix storeType to handle pointers to go:notinheap types
storeType splits compound stores up into a scalar parts and a pointer parts.
The scalar part happens unconditionally, and the pointer part happens
under the guard of a write barrier check.
Types which are declared as pointers, but are represented as scalars because
they might have "bad" values, were not handled correctly here. They ended
up not getting stored in either set.
Fixes #42151
Change-Id: I46f6600075c0c370e640b807066247237f93c7ac
Reviewed-on: https://go-review.googlesource.com/c/go/+/264300
Trust: Keith Randall <khr@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
(cherry picked from commit 933721b8c7f981229974e2603850c2e9a7ffc5a1)
Reviewed-on: https://go-review.googlesource.com/c/go/+/265719
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Keith Randall [Thu, 22 Oct 2020 23:37:19 +0000 (16:37 -0700)]
[release-branch.go1.15] cmd/compile, runtime: store pointers to go:notinheap types indirectly
pointers to go:notinheap types should be treated as scalars. That
means they shouldn't be stored directly in interfaces, or directly
in reflect.Value.ptr.
Also be sure to use uintpr to compare such pointers in reflect.DeepEqual.
Fixes #42169
Change-Id: I53735f6d434e9c3108d4940bd1bae14c61ef2a74
Reviewed-on: https://go-review.googlesource.com/c/go/+/264480
Trust: Keith Randall <khr@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
(cherry picked from commit 009d71409821a6ac4f1b32aaae2c856c20a29f92)
Reviewed-on: https://go-review.googlesource.com/c/go/+/265720
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Than McIntosh [Wed, 30 Sep 2020 16:52:47 +0000 (12:52 -0400)]
[release-branch.go1.15] cmd/{compile,link}: backport fix for issue 39757
During Go 1.15 development, a fix was added to the toolchain for issue
information. The 1.15 line tables were slightly malformed in the way
that they used the DWARF "end sequence" operator, resulting in
incorrect line table info for the final instruction in the final
function of a compilation unit.
This problem was fixed in https://golang.org/cl/235739, which made it
into Go 1.15. It now appears that while the fix works OK for linux, in
certain cases it causes issues with the Darwin linker (the "address
not in any section" ld64 error reported in issue #40974).
During Go 1.16 development, the fix in https://golang.org/cl/235739
was revised so as to fix another related problem (described in issue #39757);
the newer fix does not trigger the problem in the Darwin linker however.
This CL back-ports the changes in https://golang.org/cl/239286 to the
1.15 release branch, so as to fix the Darwin linker error.
Updates #38192.
Updates #39757.
Fixes #40974.
Change-Id: I9350fec4503cd3a76b97aaea0d8aed1511662e29
Reviewed-on: https://go-review.googlesource.com/c/go/+/258422
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com> Reviewed-by: Jeremy Faller <jeremy@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Than McIntosh <thanm@google.com>
net/http2: send WINDOW_UPDATE on a body's write failure
https://golang.org/cl/258478 (updates #41387)
Created by:
go mod edit -replace=golang.org/x/net=golang.org/x/net@release-branch.go1.15-bundle
GOFLAGS='-mod=mod' go generate -run=bundle std
go mod edit -dropreplace=golang.org/x/net
go get -d golang.org/x/net@release-branch.go1.15
go mod tidy
go mod vendor
Updates #40423
Fixes #41387
Change-Id: I052037d6b6ed38b9d9782e19b8ce283875354c92
Reviewed-on: https://go-review.googlesource.com/c/go/+/258540
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Emmanuel Odeke <emm.odeke@gmail.com>
Ian Lance Taylor [Thu, 15 Oct 2020 21:39:12 +0000 (14:39 -0700)]
[release-branch.go1.15] runtime: wait for preemption signals before syscall.Exec
For #41702
For #41704
For #42023
Change-Id: If07f40b1d73b8f276ee28ffb8b7214175e56c24d
Reviewed-on: https://go-review.googlesource.com/c/go/+/262817
Trust: Ian Lance Taylor <iant@golang.org>
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
(cherry picked from commit 05739d6f17c57f09264272621b88725a463234d0)
Reviewed-on: https://go-review.googlesource.com/c/go/+/264022
Ian Lance Taylor [Thu, 15 Oct 2020 21:19:10 +0000 (14:19 -0700)]
[release-branch.go1.15] syscall: use MustHaveExec in TestExec
For #41702
For #41704
Change-Id: Ib2b15e52aa1fef2f5e644b316c726150252fa9f8
Reviewed-on: https://go-review.googlesource.com/c/go/+/262738
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
(cherry picked from commit 11cfb48df192c14d185c1cfcaad1ba3e7b84c807)
Reviewed-on: https://go-review.googlesource.com/c/go/+/264020
Ian Lance Taylor [Wed, 14 Oct 2020 23:03:48 +0000 (16:03 -0700)]
[release-branch.go1.15] runtime: stop preemption during syscall.Exec on Darwin
On current macOS versions a program that receives a signal during an
execve can fail with a SIGILL signal. This appears to be a macOS
kernel bug. It has been reported to Apple.
This CL partially works around the problem by using execLock to not
send preemption signals during execve. Of course some other stray
signal could occur, but at least we can avoid exacerbating the problem.
We can't simply disable signals, as that would mean that the exec'ed
process would start with all signals blocked, which it likely does not
expect.
For #41702
Fixes #41704
Change-Id: I91b0add967b315671ddcf73269c4d30136e579b4
Reviewed-on: https://go-review.googlesource.com/c/go/+/262438
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
(cherry picked from commit 64fb6ae95f1c322486cbfb758552bb8439a8e6e8)
Reviewed-on: https://go-review.googlesource.com/c/go/+/262717
Alexander Rakoczy [Wed, 14 Oct 2020 17:45:23 +0000 (13:45 -0400)]
[release-branch.go1.15] go1.15.3
Change-Id: I8a45870039d0d3f210d883c464a7fed2abd9e28b
Reviewed-on: https://go-review.googlesource.com/c/go/+/262337
Run-TryBot: Alexander Rakoczy <alex@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Alexander Rakoczy <alex@golang.org>
Keith Randall [Thu, 1 Oct 2020 16:57:52 +0000 (09:57 -0700)]
[release-branch.go1.15] cmd/compile: fix left shift constant folding rule
The 32-bit left shift constant folding rule should keep its result
properly sign extended.
Fixes #41720
Fixes #41711
Change-Id: I0fc74444d444274e911952e1725dab0b7737a846
Reviewed-on: https://go-review.googlesource.com/c/go/+/258817
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Austin Clements [Sat, 3 Oct 2020 20:44:22 +0000 (16:44 -0400)]
[release-branch.go1.15] runtime: correct signature of call16
The signature of call16 is currently missing the "typ" parameter. This
CL fixes this. This wasn't caught by vet because call16 is defined by
macro expansion (see #17544), and we didn't notice the mismatch with
the other call* functions because call16 is defined only on 32-bit
architectures and lives alone in stubs32.go.
Unfortunately, this means its GC signature is also wrong: the "arg"
parameter is treated as a scalar rather than a pointer, so GC won't
trace it and stack copying won't adjust it. This turns out to matter
in exactly one case right now: on 32-bit architectures (which are the
only architectures where call16 is defined), a stack-allocated defer
of a function with a 16-byte or smaller argument frame including a
non-empty result area can corrupt memory if the deferred function
grows the stack and is invoked during a panic. Whew. All other current
uses of reflectcall pass a heap-allocated "arg" frame (which happens
to be reachable from other stack roots, so tracing isn't a problem).
Curiously, in 2016, the signatures of all call* functions were wrong
in exactly this way. CL 31654 fixed all of them in stubs.go, but
missed the one in stubs32.go.
We already correctly propagate the notinheap-ness of T to U. But we
have an assertion in the typechecker that if there's no explicit
//go:notinheap associated with U, then report an error. Get rid of
that error so that implicit propagation is allowed.
Adjust the tests so that we make sure that uses of types like U
do correctly report an error when U is used in a context that might
cause a Go heap allocation.
Update #41432
Change-Id: I1692bc7cceff21ebb3f557f3748812a40887118d
Reviewed-on: https://go-review.googlesource.com/c/go/+/255637
Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
(cherry picked from commit 22053790fa2c0944df53ea95df476ad2f855424f)
Reviewed-on: https://go-review.googlesource.com/c/go/+/255697
Trust: Keith Randall <khr@golang.org> Reviewed-by: Austin Clements <austin@google.com>
Keith Randall [Wed, 26 Aug 2020 21:17:35 +0000 (14:17 -0700)]
[release-branch.go1.15] cmd/cgo: use go:notinheap for anonymous structs
They can't reasonably be allocated on the heap. Not a huge deal, but
it has an interesting and useful side effect.
After CL 249917, the compiler and runtime treat pointers to
go:notinheap types as uintptrs instead of real pointers (no write
barrier, not processed during stack scanning, ...). That feature is
exactly what we want for cgo to fix #40954. All the cases we have of
pointers declared in C, but which might actually be filled with
non-pointer data, are of this form (JNI's jobject heirarch, Darwin's
CFType heirarchy, ...).
Fixes #40954
Change-Id: I44a3b9bc2513d4287107e39d0cbbd0efd46a3aae
Reviewed-on: https://go-review.googlesource.com/c/go/+/250940
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Keith Randall <khr@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-on: https://go-review.googlesource.com/c/go/+/255321
Keith Randall [Wed, 26 Aug 2020 21:07:35 +0000 (14:07 -0700)]
[release-branch.go1.15] cmd/compile: allow aliases to go:notinheap types
The alias doesn't need to be marked go:notinheap. It gets its
notinheap-ness from the target type.
Without this change, the type alias test in the notinheap.go file
generates these two errors:
notinheap.go:62: misplaced compiler directive
notinheap.go:63: type nih must be go:notinheap
The first is a result of go:notinheap pragmas not applying
to type alias declarations.
The second is the result of then trying to match the notinheap-ness
of the alias and the target type.
Add a few more go:notinheap tests while we are here.
Update #40954
Change-Id: I067ec47698df6e9e593e080d67796fd05a1d480f
Reviewed-on: https://go-review.googlesource.com/c/go/+/250939
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Trust: Keith Randall <khr@golang.org>
Reviewed-on: https://go-review.googlesource.com/c/go/+/255337
Trust: Emmanuel Odeke <emm.odeke@gmail.com> Reviewed-by: Austin Clements <austin@google.com>
Keith Randall [Sat, 22 Aug 2020 03:20:12 +0000 (20:20 -0700)]
[release-branch.go1.15] cmd/compile: don't allow go:notinheap on the heap or stack
Right now we just prevent such types from being on the heap. This CL
makes it so they cannot appear on the stack either. The distinction
between heap and stack is pretty vague at the language level (e.g. it
is affected by -N), and we don't need the flexibility anyway.
Once go:notinheap types cannot be in either place, we don't need to
consider pointers to such types to be pointers, at least according to
the garbage collector and stack copying. (This is the big win of this
CL, in my opinion.)
The distinction between HasPointers and HasHeapPointer no longer
exists. There is only HasPointers.
This CL is cleanup before possible use of go:notinheap to fix #40954.
Update #13386
Change-Id: Ibd895aadf001c0385078a6d4809c3f374991231a
Reviewed-on: https://go-review.googlesource.com/c/go/+/255320
Trust: Keith Randall <khr@golang.org> Reviewed-by: Austin Clements <austin@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Keith Randall [Sun, 23 Aug 2020 18:52:53 +0000 (11:52 -0700)]
[release-branch.go1.15] runtime: implement StorepNoWB for wasm in assembly
The second argument of StorepNoWB must be forced to escape.
The current Go code does not explicitly enforce that property.
By implementing in assembly, and not using go:noescape, we
force the issue.
Test is in CL 249761. Issue #40975.
This CL is needed for CL 249917, which changes how go:notinheap
works and breaks the previous StorepNoWB wasm code.
I checked for other possible errors like this. This is the only
go:notinheap that isn't in the runtime itself.
Included test from CL 249761.
Update #41432
Change-Id: I43400a806662655727c4a3baa8902b63bdc9fa57
Reviewed-on: https://go-review.googlesource.com/c/go/+/249962
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
(cherry picked from commit c0602603b20186228b4f89f265cb3f7665e06768)
Reviewed-on: https://go-review.googlesource.com/c/go/+/260878
Trust: Keith Randall <khr@golang.org>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Ian Lance Taylor [Wed, 7 Oct 2020 23:37:05 +0000 (16:37 -0700)]
[release-branch.go1.15] cmd/cgo: add more architectures to size maps
This brings over the architectures that the gofrontend knows about.
This permits using the main cgo tool for those architectures,
as cgo can be used with -godefs without gc support.
This will help add golang.org/x/sys/unix support for other architectures.
For #37443
Fixes #41871
Change-Id: I63632b9c5139e71b9ccab8edcc7acdb464229b74
Reviewed-on: https://go-review.googlesource.com/c/go/+/260657
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com>
(cherry picked from commit 5d1378143bc07791296abb420df35537ad80492f)
Reviewed-on: https://go-review.googlesource.com/c/go/+/260702
The IndexString implementation in the bytealg package requires that
the string passed into it be in the range '2 <= len(s) <= MaxLen'
where MaxLen may be any value (including 0).
CL 156998 added calls to bytealg.IndexString where MaxLen was not
first checked. This led to an illegal instruction on s390x with
the vector facility disabled.
This CL guards the calls to bytealg.IndexString with a MaxLen check.
If the check fails then the code now falls back to the pre CL 156998
implementation (a loop over the runes in the string).
Since the MaxLen check is now in place the generic implementation is
no longer called so I have returned it to its original unimplemented
state.
In future we may want to drop MaxLen to prevent this kind of
confusion.
Fixes #41595.
Change-Id: I81d88cf8c5ae143a8f5f460d18f8269cb6c0f28c
Reviewed-on: https://go-review.googlesource.com/c/go/+/256921
Trust: Michael Munday <mike.munday@ibm.com>
Run-TryBot: Michael Munday <mike.munday@ibm.com> Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Daniel Martí [Thu, 10 Sep 2020 21:53:59 +0000 (22:53 +0100)]
[release-branch.go1.15] cmd/go: relax version's error on unexpected flags
In https://golang.org/cl/221397 we made commands like "go version -v"
error, since both of the command's flags only make sense when arguments
follow them. Without arguments, the command only reports Go's own
version, and the flags are most likely a mistake.
However, the script below is entirely reasonable:
export GOFLAGS=-v # make all Go commands verbose
go version
go build
After the previous CL, "go version" would error. Instead, only error if
the flag was passed explicitly, and not via GOFLAGS.
The patch does mean that we won't error on "GOFLAGS=-v go version -v",
but that very unlikely false negative is okay. The error is only meant
to help the user not misuse the flags, anyway - it's not a critical
error of any sort.
To reuse inGOFLAGS, we move it to the base package and export it there,
since it's where the rest of the GOFLAGS funcs are.
Fixes #41464.
Change-Id: I74003dd25d94bacf9ac507b5cad778fd65233321
Reviewed-on: https://go-review.googlesource.com/c/go/+/254157
Trust: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
(cherry picked from commit de0957dc081e1ec49c99a0f37403ceadbaaedf85)
Reviewed-on: https://go-review.googlesource.com/c/go/+/255498
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Michael Anthony Knyszek [Mon, 10 Aug 2020 20:02:22 +0000 (20:02 +0000)]
[release-branch.go1.15] runtime: disable stack shrinking in activeStackChans race window
Currently activeStackChans is set before a goroutine blocks on a channel
operation in an unlockf passed to gopark. The trouble is that the
unlockf is called *after* the G's status is changed, and the G's status
is what is used by a concurrent mark worker (calling suspendG) to
determine that a G has successfully been suspended. In this window
between the status change and unlockf, the mark worker could try to
shrink the G's stack, and in particular observe that activeStackChans is
false. This observation will cause the mark worker to *not* synchronize
with concurrent channel operations when it should, and so updating
pointers in the sudog for the blocked goroutine (which may point to the
goroutine's stack) races with channel operations which may also
manipulate the pointer (read it, dereference it, update it, etc.).
Fix the problem by adding a new atomically-updated flag to the g struct
called parkingOnChan, which is non-zero in the race window above. Then,
in isShrinkStackSafe, check if parkingOnChan is zero. The race is
resolved like so:
* Blocking G sets parkingOnChan, then changes status in gopark.
* Mark worker successfully suspends blocking G.
* If the mark worker observes parkingOnChan is non-zero when checking
isShrinkStackSafe, then it's not safe to shrink (we're in the race
window).
* If the mark worker observes parkingOnChan as zero, then because
the mark worker observed the G status change, it can be sure that
gopark's unlockf completed, and gp.activeStackChans will be correct.
The risk of this change is low, since although it reduces the number of
places that stack shrinking is allowed, the window here is incredibly
small. Essentially, every place that it might crash now is replaced with
no shrink.
This change adds a test, but the race window is so small that it's hard
to trigger without a well-placed sleep in park_m. Also, this change
fixes stackGrowRecursive in proc_test.go to actually allocate a 128-byte
stack frame. It turns out the compiler was destructuring the "pad" field
and only allocating one uint64 on the stack.
For #40641.
Fixes #40643.
Change-Id: I7dfbe7d460f6972b8956116b137bc13bc24464e8
Reviewed-on: https://go-review.googlesource.com/c/go/+/247050
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
(cherry picked from commit eb3c6a93c3236bbde5dee6cc5bd4ca9f8ab1647a)
Reviewed-on: https://go-review.googlesource.com/c/go/+/256300 Reviewed-by: Austin Clements <austin@google.com>
[release-branch.go1.15] cmd/addr2line: don't assume that GOROOT_FINAL is clean
Updates #41447
Fixes #41453
Change-Id: I4460c1c7962d02c41622a5ea1a3c4bc3714a1873
Reviewed-on: https://go-review.googlesource.com/c/go/+/255477
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
(cherry picked from commit 6796a7fb127676b61375339076ae1c982a721dde)
Reviewed-on: https://go-review.googlesource.com/c/go/+/255658
Keith Randall [Sat, 8 Aug 2020 14:58:04 +0000 (07:58 -0700)]
[release-branch.go1.15] cmd/compile: fix live variable computation for deferreturn
Taking the live variable set from the last return point is problematic.
See #40629 for details, but there may not be a return point, or it may
be before the final defer.
Additionally, keeping track of the last call as a *Value doesn't quite
work. If it is dead-code eliminated, the storage for the Value is reused
for some other random instruction. Its live variable information,
if it is available at all, is wrong.
Instead, just mark all the open-defer argument slots as live
throughout the function. (They are already zero-initialized.)
Fixes #40742
Change-Id: Ie456c7db3082d0de57eaa5234a0f32525a1cce13
Reviewed-on: https://go-review.googlesource.com/c/go/+/247522
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Dan Scales <danscales@google.com>
(cherry picked from commit 32a84c99e136ed5af0686dbedd31fd7dff40fb38)
Reviewed-on: https://go-review.googlesource.com/c/go/+/248621
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Bryan C. Mills [Wed, 19 Aug 2020 02:47:12 +0000 (22:47 -0400)]
[release-branch.go1.15] testing: flush test summaries to stdout atomically when streaming output
While debugging #40771, I realized that the chatty printer should only
ever print to a single io.Writer (normally os.Stdout). The other
Writer implementations in the chain write to local buffers, but if we
wrote a test's output to a local buffer, then we did *not* write it to
stdout and we should not store it as the most recently logged test.
Because the chatty printer should only ever print to one place, it
shouldn't receive an io.Writer as an argument — rather, it shouldn't
be used at all for destinations other than the main output stream.
On the other hand, when we flush the output buffer to stdout in the
top-level flushToParent call, it is important that we not allow some
other test's output to intrude between the test summary header and the
remainder of the test's output. cmd/test2json doesn't know how to
parse such an intrusion, and it's confusing to humans too.
No test because I couldn't reproduce the user-reported error without
modifying the testing package. (This behavior seems to be very
sensitive to output size and/or goroutine scheduling.)
Fixes #40881
Updates #40771
Updates #38458
Change-Id: Ic19bf1d535672b096ba1c8583a3b74aab6d6d766
Reviewed-on: https://go-review.googlesource.com/c/go/+/249026
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
(cherry picked from commit 51c0bdc6d15dcd7f753c25896039ab41ac787ebb)
Reviewed-on: https://go-review.googlesource.com/c/go/+/252637
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Bryan C. Mills <bcmills@google.com>
Keith Randall [Thu, 24 Sep 2020 21:25:21 +0000 (14:25 -0700)]
[release-branch.go1.15] cmd/compile: prevent 387+float32+pie from clobbering registers
The 387 port needs to load a floating-point control word from a
global location to implement float32 arithmetic.
When compiling with -pie, loading that control word clobbers an
integer register. If that register had something important in it, boom.
Fix by using LEAL to materialize the address of the global location
first. LEAL with -pie works because the destination register is
used as the scratch register.
387 support is about to go away (#40255), so this will need to be
backported to have any effect.
No test. I have one, but it requires building with -pie, which
requires cgo. Our testing infrastructure doesn't make that easy.
Not worth it for a port which is about to vanish.
Fixes #41620
Change-Id: I140f9fc8fdce4e74a52c2c046e2bd30ae476d295
Reviewed-on: https://go-review.googlesource.com/c/go/+/257277
Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Keith Randall <khr@golang.org>
(cherry picked from commit ea106cc07ac73110a8a25fcc5aef07b283159db0)
Reviewed-on: https://go-review.googlesource.com/c/go/+/257207
Ian Lance Taylor [Tue, 22 Sep 2020 00:05:11 +0000 (17:05 -0700)]
[release-branch.go1.15] internal/poll: adjust ignoringEINTR to avoid slice escape
The 1.15 compiler is not quite smart enough to see that the byte slice
passed to ignoringEINTR does not escape. This ripples back up to user
code which would see a byte slice passed to os.(*File).Write escape,
which did not happen in 1.14.
Rather than backport some moderately complex compiler fixes, rewrite
the code slightly so that the 1.15 compiler is able to see that the
slice does not escape.
This is not a backport from tip, where the code is already different.
The test for this will be on tip, where we will most likely change the
compiler to understand this kind of code.
Fixes #41543
For #41474
Change-Id: I6c78164229fea7794e7edba512bfd7034a0b91c3
Reviewed-on: https://go-review.googlesource.com/c/go/+/256418
Trust: Ian Lance Taylor <iant@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Michael Anthony Knyszek [Wed, 9 Sep 2020 16:52:18 +0000 (16:52 +0000)]
[release-branch.go1.15] runtime: fix ReadMemStatsSlow's and CheckScavengedBits' chunk iteration
Both ReadMemStatsSlow and CheckScavengedBits iterate over the page
allocator's chunks but don't actually check if they exist. During the
development process the chunks index became sparse, so now this was a
possibility. If the runtime tests' heap is sparse we might end up
segfaulting in either one of these functions, though this will generally
be very rare.
The pattern here to return nil for a nonexistent chunk is also useful
elsewhere, so this change introduces tryChunkOf which won't throw, but
might return nil. It also updates the documentation of chunkOf.
For #41296.
Fixes #41317.
Change-Id: Id5ae0ca3234480de1724fdf2e3677eeedcf76fa0
Reviewed-on: https://go-review.googlesource.com/c/go/+/253777
Run-TryBot: Michael Knyszek <mknyszek@google.com> Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
(cherry picked from commit 34835df04891a1d54394888b763af88f9476101d)
Reviewed-on: https://go-review.googlesource.com/c/go/+/253917
Michael Munday [Mon, 10 Aug 2020 15:01:21 +0000 (08:01 -0700)]
[release-branch.go1.15] cmd/internal/obj: fix inline marker issue on s390x
The optimization that replaces inline markers with pre-existing
instructions assumes that 'Prog' values produced by the compiler are
still reachable after the assembler has run. This was not true on
s390x where the assembler was removing NOP instructions from the
linked list of 'Prog' values. This led to broken inlining data
which in turn caused an infinite loop in the runtime traceback code.
Fix this by stopping the s390x assembler backend removing NOP
values. It does not make any difference to the output of the
assembler because NOP instructions are 0 bytes long anyway.
Note: compiler check omitted from backport to reduce risk of change.
Fixes #40693.
Change-Id: I4eb570de13165cde342d5fb2ee3218945ddf4b52
Reviewed-on: https://go-review.googlesource.com/c/go/+/248478
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
It clobbers R12 (and CTR, which is never live across a call).
As at compile time we don't know whether the binary is big and
what link mode will be used, I think we need to mark R12 as
clobbered for write barrier call. For extra safety (future-proof)
we mark caller-saved register that cannot be used for function
arguments, which includes R11, as potentially clobbered as well.
Lynn Boger [Tue, 11 Aug 2020 16:04:25 +0000 (12:04 -0400)]
[release-branch.go1.15] cmd/internal/obj/ppc64: don't remove NOP in assembler
Previously, the assembler removed NOPs from the Prog list in
obj9.go. NOPs shouldn't be removed if they were added as
an inline mark, as described in the issue below.
Fixes #40767
Once the NOPs were left in the Prog list, some instructions
were flagged as invalid because they had an operand which was
not represented in optab. In order to preserve the previous
assembler behavior, entries were added to optab for those
operand cases. They were not flagged as errors before because
the NOP instructions were removed before the code to check the
valid opcode/operand combinations.
Change-Id: Iae5145f94459027cf458e914d7c5d6089807ccf8
Reviewed-on: https://go-review.googlesource.com/c/go/+/247842
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Paul Murphy <murp@ibm.com> Reviewed-by: Michael Munday <mike.munday@ibm.com> Reviewed-by: Keith Randall <khr@golang.org>
(cherry picked from commit 7d7bd5abc7f7ac901830b79496f63ce86895e262)
Reviewed-on: https://go-review.googlesource.com/c/go/+/248381
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Bryan C. Mills [Fri, 14 Aug 2020 21:44:22 +0000 (17:44 -0400)]
[release-branch.go1.15] cmd/test2json: do not emit a final Action if the result is not known
If we are parsing a test output, and the test does not end in the
usual PASS or FAIL line (say, because it panicked), then we need the
exit status of the test binary in order to determine whether the test
passed or failed. If we don't have that status available, we shouldn't
guess arbitrarily — instead, we should omit the final "pass" or "fail"
action entirely.
(In practice, we nearly always DO have the final status, such as when
running 'go test' or 'go tool test2json some.exe'.)
Updates #40132
Fixes #40805
Change-Id: Iae482577361a6033395fe4a05d746b980e18c3de
Reviewed-on: https://go-review.googlesource.com/c/go/+/248624
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
(cherry picked from commit 1b86bdbdc3991c13c6ed156100a5f4918fdd9c6b)
Reviewed-on: https://go-review.googlesource.com/c/go/+/248725
chainhelen [Fri, 21 Aug 2020 16:44:52 +0000 (16:44 +0000)]
[release-branch.go1.15] runtime: fix panic if newstack at runtime.acquireLockRank
Process may crash becaues acquireLockRank and releaseLockRank may
be called in nosplit context. With optimizations and inlining
disabled, these functions won't get inlined or have their morestack
calls eliminated.
Nosplit is not strictly required for lockWithRank, unlockWithRank
and lockWithRankMayAcquire, just keep consistency with lockrank_on.go
here.
Bryan C. Mills [Mon, 17 Aug 2020 21:31:21 +0000 (17:31 -0400)]
[release-branch.go1.15] testing: treat PAUSE lines as changing the active test name
We could instead fix cmd/test2json to treat PAUSE lines as *not*
changing the active test name, but that seems like it would be more
confusing to humans, and also wouldn't fix tools that parse output
using existing builds of cmd/test2json.
Fixes #40849
Updates #40657
Change-Id: I937611778f5b1e7dd1d6e9f44424d7e725a589ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/248727
Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Jean de Klerk <deklerk@google.com>
(cherry picked from commit cdc77d34d7770ed02d84b9193380f9646017dce6)
Reviewed-on: https://go-review.googlesource.com/c/go/+/249097
TryBot-Result: Gobot Gobot <gobot@golang.org>
This CL ensures that responses served via CGI and FastCGI
have a Content-Type header based on the content of the
response if not explicitly set by handlers.
If the implementers of the handler did not explicitly
specify a Content-Type both CGI implementations would default
to "text/html", potentially causing cross-site scripting.
Thanks to RedTeam Pentesting GmbH for reporting this.
Fixes CVE-2020-24553
Change-Id: I82cfc396309b5ab2e8d6e9a87eda8ea7e3799473
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/823217 Reviewed-by: Russ Cox <rsc@google.com>
(cherry picked from commit 23d675d07fdc56aafd67c0a0b63d5b7e14708ff0)
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/835311 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Jason A. Donenfeld [Tue, 14 Jul 2020 07:41:03 +0000 (01:41 -0600)]
[release-branch.go1.15] runtime: detect services in signal handler
The service handler needs to handle CTRL+C-like events -- including
those sent by the service manager itself -- using the default Windows
implementation if no signal handler from Go is already listening to
those events. Ordinarily, the signal handler would call exit(2), but we
actually need to allow this to be passed onward to the service handler.
So, we detect if we're in a service and skip calling exit(2) in that
case, just like we do for shared libraries.
Updates #40167.
Updates #40074.
Fixes #40412.
Change-Id: Ia77871737a80e1e94f85b02d26af1fd2f646af96
Reviewed-on: https://go-review.googlesource.com/c/go/+/244959
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Alex Brainman <alex.brainman@gmail.com>