Adapt the testcshared tests to handle the case where the path output
by invoking
gcc -print-prog-name=dlltool
is a path lacking the final ".exe" suffix (this seems to be what clang
is doing); tack it on before using if this is the case.
Updates #57704.
Fixes#57705.
Change-Id: I04fb7b9fc90677880b1ced4a4ad2a8867a3f5f86
Reviewed-on: https://go-review.googlesource.com/c/go/+/451816
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
(cherry picked from commit 771a98d6b19c9ca4bbd3fbeba03d7d512f77c166)
Reviewed-on: https://go-review.googlesource.com/c/go/+/461176
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
A recent comment on #57263 reports an unexplained crash in a cgo program
that is fixed by reverting the __fork fix. We don't have any viable fix for the
os/exec bug at this point, so give up on a fix for the January point releases.
This reverts CL 459179 (commit 07b6ffb79c90).
Fixes#57689.
Change-Id: I3b81de6bded399f47862325129e86a65c83d8e3b
Reviewed-on: https://go-review.googlesource.com/c/go/+/461116
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
On macOS return the error code from SecTrustEvaluateWithError, and use
it to create typed errors that can be returned from Verify.
Updates #56891Fixes#57426
Change-Id: Ib597ce202abb60702f730e75da583894422e4c14
Reviewed-on: https://go-review.googlesource.com/c/go/+/452620
Run-TryBot: Roland Shoemaker <roland@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
(cherry picked from commit c9a10d48a8f0e8479f5b9d98c5bd81b64a90d23d)
Reviewed-on: https://go-review.googlesource.com/c/go/+/460896
Reviewed-by: Carlos Amedee <carlos@golang.org>
Auto-Submit: Heschi Kreinick <heschi@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
The function LoweredAtomicCas32 is implemented using the LL-SC instruction pair
on loong64, mips64x, riscv64. However,the LL instruction on loong64, mips64x,
riscv64 is sign-extended, so it is necessary to sign-extend the 2nd parameter
"old" of the LoweredAtomicCas32, so that the instruction BNE after LL can get
the desired result.
The function prototype of LoweredAtomicCas32 in golang:
func Cas32(ptr *uint32, old, new uint32) bool
When using an intrinsify implementation:
case 1: (*ptr) <= 0x80000000 && old < 0x80000000
E.g: (*ptr) = 0x7FFFFFFF, old = Rarg1= 0x7FFFFFFF
After run the instruction "LL (Rarg0), Rtmp": Rtmp = 0x7FFFFFFF
Rtmp ! = Rarg1(old) is false, the result we expect
case 2: (*ptr) >= 0x80000000 && old >= 0x80000000
E.g: (*ptr) = 0x80000000, old = Rarg1= 0x80000000
After run the instruction "LL (Rarg0), Rtmp": Rtmp = 0xFFFFFFFF_80000000
Rtmp ! = Rarg1(old) is true, which we do not expect
When using an non-intrinsify implementation:
Because Rarg1 is loaded from the stack using sign-extended instructions
ld.w, the situation described in Case 2 above does not occur
Benchmarks on linux/loong64:
name old time/op new time/op delta
Cas 50.0ns ± 0% 50.1ns ± 0% ~ (p=1.000 n=1+1)
Cas64 50.0ns ± 0% 50.1ns ± 0% ~ (p=1.000 n=1+1)
Cas-4 56.0ns ± 0% 56.0ns ± 0% ~ (p=1.000 n=1+1)
Cas64-4 56.0ns ± 0% 56.0ns ± 0% ~ (p=1.000 n=1+1)
Benchmarks on Loongson 3A4000 (GOARCH=mips64le, 1.8GHz)
name old time/op new time/op delta
Cas 70.4ns ± 0% 70.3ns ± 0% ~ (p=1.000 n=1+1)
Cas64 70.7ns ± 0% 70.6ns ± 0% ~ (p=1.000 n=1+1)
Cas-4 81.1ns ± 0% 80.8ns ± 0% ~ (p=1.000 n=1+1)
Cas64-4 80.9ns ± 0% 80.9ns ± 0% ~ (p=1.000 n=1+1)
Fixes#57344
Change-Id: I190a7fc648023b15fa392f7fdda5ac18c1561bac
Reviewed-on: https://go-review.googlesource.com/c/go/+/457135
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Wayne Zuo <wdvxdr@golangcn.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/458357
Run-TryBot: David Chase <drchase@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
Issues #33565 and #56784 were caused by hangs in the child process
after fork, while it ran atfork handlers that ran into slow paths that
didn't work in the child.
CL 451735 worked around those two issues by calling a couple functions
at startup to try to warm up those child paths. That mostly worked,
but it broke programs using cgo with certain macOS frameworks (#57263).
CL 459175 reverted CL 451735.
This CL introduces a different fix: bypass the atfork child handlers
entirely. For a general fork call where the child and parent are both
meant to keep executing the original program, atfork handlers can be
necessary to fix any state that would otherwise be tied to the parent
process. But Go only uses fork as preparation for exec, and it takes
care to limit what it attempts to do in the child between the fork and
exec. In particular it doesn't use any of the things that the macOS
atfork handlers are trying to fix up (malloc, xpc, others). So we can
use the low-level fork system call (__fork) instead of the
atfork-wrapped one.
The full list of functions that can be called in a child after fork in
exec_libc2.go is:
- ptrace
- setsid
- setpgid
- getpid
- ioctl
- chroot
- setgroups
- setgid
- setuid
- chdir
- dup2
- fcntl
- close
- execve
- write
- exit
I disassembled all of these while attached to a hung exec.test binary
and confirmed that nearly all of them are making direct kernel calls,
not using anything that the atfork handler needs to fix up.
The exceptions are ioctl, fcntl, and exit.
The ioctl and fcntl implementations do some extra work around the
kernel call but don't call any other functions, so they should still
be OK. (If not, we could use __ioctl and __fcntl instead, but without
a good reason, we should keep using the standard entry points.)
The exit implementation calls atexit handlers. That is almost
certainly inappropriate in a failed fork child, so this CL changes
that call to __exit on darwin. To avoid making unnecessary changes at
this point in the release cycle, this CL leaves OpenBSD calling plain
exit, even though that is probably a bug in the OpenBSD port
(filed #57446).
Fixes#33565.
Fixes#56784.
Fixes#57263.
Fixes#56836.
Change-Id: I26812c26a72bdd7fcf72ec41899ba11cf6b9c4ab
Reviewed-on: https://go-review.googlesource.com/c/go/+/459176
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-on: https://go-review.googlesource.com/c/go/+/459179
Our minimum Linux version is 2.6.32, and the accept4 system call was
introduced in 2.6.28, so we use accept4 everywhere. Unfortunately,
it turns out that the accept4 system call was only added to
linux-arm in 2.6.36, so for linux-arm only we need to try the accept4
system call and then fall back to accept if it doesn't work.
The code we use on linux-arm is the code we used in Go 1.17.
On non-arm platforms we continue using the simpler code introduced
in Go 1.18.
Adding accept4 to the ARM Linux kernel was:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=21d93e2e29722d7832f61cc56d73fb953ee6578e
For #57333Fixes#57338
Change-Id: I6680cb54dd4d3514a6887dda8906e6708c64459d
Reviewed-on: https://go-review.googlesource.com/c/go/+/457997
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
https://reviews.llvm.org/D123534 is emitting DW_TAG_variable's that don't have a DW_AT_name. This is allowed in the DWARF standard. It is adding DIE's for string literals for better symbolization on buffer overlows etc on these strings. They no associated name because they are not user provided variables.
Fixes#57044
Updates #53000
Change-Id: I2cf063160508687067c7672cef0517bccd707d7b
Reviewed-on: https://go-review.googlesource.com/c/go/+/406816
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
(cherry picked from commit e66f895667cd51d0d28c42d369a803c12db8bb35)
Change-Id: I2cf063160508687067c7672cef0517bccd707d7b
GitHub-Last-Rev: 32208e4fa20272b80cfffd95a4701e1473f47ca9
GitHub-Pull-Request: golang/go#57067
Reviewed-on: https://go-review.googlesource.com/c/go/+/455055
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Similar to CL 456556 but for ppc64 instead of arm64.
Change docs about how booleans are stored in registers for ppc64.
We now don't promise to keep the upper bits zeroed; they might be junk.
To test, I changed the boolean generation instructions (MOVBZload* and ISEL*
with boolean type) to OR in 0x100 to the result. all.bash still passed,
so I think nothing else is depending on the upper bits of booleans.
Update #57211
Change-Id: Ie66f8934a0dafa34d0a8c2a37324868d959a852c
Reviewed-on: https://go-review.googlesource.com/c/go/+/456437
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: KAMPANAT THUMWONG (KONG PC) <1992kongpc.kth@gmail.com>
Run-TryBot: Archana Ravindar <aravind5@in.ibm.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/456735
Reviewed-by: Than McIntosh <thanm@google.com>
ARM64 maintains booleans in the low byte of registers. Upper parts
of that register are junk.
This rule is using all 32 bits of a boolean-containing register, which
is wrong. Change the rule to only look at the low bit.
Fixes#57211
Change-Id: Ibbef86b2be859df3d06d993db00e1231c481c428
Reviewed-on: https://go-review.googlesource.com/c/go/+/456556
Auto-Submit: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-on: https://go-review.googlesource.com/c/go/+/456558
Reviewed-by: Than McIntosh <thanm@google.com>
Update x/net to include the fix for #53960.
For #53960
For #56323
Change-Id: I825212ecdf7bf2f52c2fda1faf1739b593063653
Reviewed-on: https://go-review.googlesource.com/c/go/+/457596
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
Tested by temporarily changing sysdir to use a directory where
the expected files were all symlinks. We should consider using
a different approach that doesn't rely on sysdir, but for now
do a minimal fix.
For #57210Fixes#57213
Change-Id: Ifb1becef03e014ceb48290ce13527b3e103c0e07
Reviewed-on: https://go-review.googlesource.com/c/go/+/456557
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
(cherry picked from commit 9b8750f53ed89fb326e4d811524e647683136bac)
Reviewed-on: https://go-review.googlesource.com/c/go/+/456561
Reviewed-by: Austin Clements <austin@google.com>
If a compatible trampoline has been inserted by a previously laid
function in the same section, and is known to be sufficiently close,
it can be reused.
When testing if the trampoline can be reused, the addend of the direct
call should be ignored. It is already encoded in the trampoline. If the
addend is non-zero, and the target sufficiently far away, and just
beyond direct call reach, this may cause the trampoline to be
incorrectly reused.
This was observed on go1.17.13 and openshift-installer commit f3c53b382
building in release mode with the following error:
github.com/aliyun/alibaba-cloud-sdk-go/services/cms.(*Client).DescribeMonitoringAgentAccessKeyWithChan.func1: direct call too far: runtime.duffzero+1f0-tramp0-1 -2000078
Fixes#56833
Change-Id: I54af957302506d4e3cd5d3121542c83fe980e912
Reviewed-on: https://go-review.googlesource.com/c/go/+/451415
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/451916
Reviewed-by: Joedian Reid <joedian@golang.org>
This was a regression test added for a 'git' command line
used for build stamping. Unfortunately, 'gpg' has proved to
be extremely fragile:
* In recent versions, it appears to always require 'gpg-agent' to be
installed for anything involving secret keys, but for some reason is
not normally marked as requiring gpg-agent in Debian's package
manager.
* It tries to create a Unix domain socket in a subdirectory of $TMPDIR
without checking the path length, which fails when $TMPDIR is too
long to fit in the 'sun_path' field of a sockaddr_un struct (which
typically tops out somewhere between 92 and 108 bytes).
We could theoretically address those by artificially reducing the
script's TMPDIR length and checking for gpg-agent in addition to gpg,
but arguably those should both be fixed upstream instead. On balance,
the incremental value that this test provides does not seem worth the
complexity of dealing with such a fragile third-party tool.
Updates #50675.
Updates #48802.
Updates #57034.
Fixes#57054.
Change-Id: Ia3288c2f84f8db86ddfa139b4d1c0112d67079ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/454502
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
(cherry picked from commit 45f5ef4ed7a774b6911650319a265e17ee9e6e0e)
Reviewed-on: https://go-review.googlesource.com/c/go/+/454956
TestLookupDotsWithRemoteSource and TestLookupGoogleSRV
were disabled because they look up the no-longer-present
SRV record for _xmpp-server._tcp.google.com.
Change the tests to look for _ldap._tcp.google.com and
reenable them.
For #56708.
Fixes#56711.
Change-Id: I26475fa3ff6fc008048a4e5f24f0e96ee12f655c
Reviewed-on: https://go-review.googlesource.com/c/go/+/453861
Run-TryBot: Damien Neil <dneil@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
(cherry picked from commit cb42bbddeb80ff08599079ee6b94088e5be88e5b)
Reviewed-on: https://go-review.googlesource.com/c/go/+/454295
Auto-Submit: Damien Neil <dneil@google.com>
Reviewed-by: Jenny Rakoczy <jenny@golang.org>
(Until it can be made hermetic.)
The gopkg.in service has had a lot of flakiness lately. Go users in
general are isolated from that flakiness by the Go module mirror
(proxy.golang.org), but this test intentionally bypasses the module
mirror because the mirror itself uses cmd/go to download the module.
In the long term, we can redirect the gopkg.in URL to the local
(in-process) vcweb server added for #27494.
In the meantime, let's skip the test to reduce the impact of upstream
outages.
Fixes#57057.
Updates #54503.
Change-Id: Icf3de7ca416db548e53864a71776fe22b444fcea
Reviewed-on: https://go-review.googlesource.com/c/go/+/454503
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
(cherry picked from commit c5f5cb659adda026d01b7fa9bd39b2ad3b58c5bf)
Reviewed-on: https://go-review.googlesource.com/c/go/+/454840
Do not permit access to Windows reserved device names (NUL, COM1, etc.)
via os.DirFS and http.Dir filesystems.
Avoid escapes from os.DirFS(`\`) on Windows. DirFS would join the
the root to the relative path with a path separator, making
os.DirFS(`\`).Open(`/foo/bar`) open the path `\\foo\bar`, which is
a UNC name. Not only does this not open the intended file, but permits
reference to any file on the system rather than only files on the
current drive.
Make os.DirFS("") invalid, with all file access failing. Previously,
a root of "" was interpreted as "/", which is surprising and probably
unintentional.
Fixes CVE-2022-41720.
Fixes#56694.
Change-Id: I275b5fa391e6ad7404309ea98ccc97405942e0f0
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1663832
Reviewed-by: Julie Qiu <julieqiu@google.com>
Reviewed-by: Tatiana Bradley <tatianabradley@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/455360
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Jenny Rakoczy <jenny@golang.org>
Fixes#57028
Updates #53013
Change-Id: I169d4eb2420a6da52cc9abe17da98c3092a91be6
Reviewed-on: https://go-review.googlesource.com/c/go/+/407514
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
(cherry picked from commit 2cfbef438049fd4c3f73d1562773ad1f93900897)
Reviewed-on: https://go-review.googlesource.com/c/go/+/454415
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
When the GC is scanning some memory (possibly conservatively),
finding a pointer, while concurrently another goroutine is
allocating an object at the same address as the found pointer, the
GC may see the pointer before the object and/or the heap bits are
initialized. This may cause the GC to see bad pointers and
possibly crash.
To prevent this, we make it that the scanner can only see the
object as allocated after the object and the heap bits are
initialized. Currently the allocator uses freeindex to find the
next available slot, and that code is coupled with updating the
free index to a new slot past it. The scanner also uses the
freeindex to determine if an object is allocated. This is somewhat
racy. This CL makes the scanner use a different field, which is
only updated after the object initialization (and a memory
barrier).
Updates #54596.
Fixes#56751.
Change-Id: I2a57a226369926e7192c253dd0d21d3faf22297c
Reviewed-on: https://go-review.googlesource.com/c/go/+/449017
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
(cherry picked from commit febe7b8e2a4dd7cce6ab8d02cf79a5430819cbe5)
Reviewed-on: https://go-review.googlesource.com/c/go/+/453255
These tests fail consistently due to a DNS change causing widespread
trybot outages.
For #56707.
Fixes#56709.
Change-Id: Iebdf91254a922a48880021198f0f12f6bc16b6e7
Reviewed-on: https://go-review.googlesource.com/c/go/+/449640
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
(cherry picked from commit 97765249082b6835c77517a4e63bb38cfd6db97b)
Reviewed-on: https://go-review.googlesource.com/c/go/+/449505
Reviewed-by: Ian Lance Taylor <iant@google.com>
The traceback code has special "jump stack" logic, to trace back
stack switches through systemstack. If we're at the entry of
systemstack, the stack switch hasn't happened, so don't jump to
user stack.
The jump stack logic is only used if we're on the g0 stack. It can
happen that we're at the entry of a recursive systemstack call on
the g0 stack. In we jump stack here, there will be two problems:
1. There are frames between entering the g0 stack and this
recursive systemstack call. Those frames will be lost.
2. Worse, we switched frame.sp but frame.fp calculation will use
the entry SP delta (0), which will be wrong, which in turn
leads wrong frame.lr and things will go off.
For now, don't jump stack if we're at entry of systemstack (SP
delta is 0).
Using a per-PC SPWRITE marker may be a better fix. If we haven't
written the SP, we haven't switched the stack so we can just
unwind like a normal function.
Updates #55851.
Fixes#56635.
Change-Id: I2b624c8c086b235b34d9c7d3cebd4a37264f00f8
Reviewed-on: https://go-review.googlesource.com/c/go/+/437299
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
(cherry picked from commit 500bc6b8056ee2eaf7640610a48ffa00bdd896a5)
Reviewed-on: https://go-review.googlesource.com/c/go/+/448517
Prior to Go 1.18, ineffectual //go:linkname directives (i.e.,
directives referring to an undeclared name, or to a declared type or
constant) were treated as noops. In Go 1.18, we changed this into a
compiler error to mitigate accidental misuse.
However, the x/sys repo contained ineffectual //go:linkname directives
up until go.dev/cl/274573, which has caused a lot of user confusion.
It seems a bit late to worry about now, but to at least prevent
further user pain, this CL changes the error message to only apply to
modules using "go 1.18" or newer. (The x/sys repo declared "go 1.12"
at the time go.dev/cl/274573 was submitted.)
For #55889.
Fixes#56556.
Change-Id: Id762fff96fd13ba0f1e696929a9e276dfcba2620
Reviewed-on: https://go-review.googlesource.com/c/go/+/447755
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/447815
Plan 9 uses NUL as os.PathListSeparator, so it's almost always going
to appear in the environment variable list. Exempt GOOS=plan9 from the
check for NUL in environment variables.
For #56284.
For #56544.
Fixes#56550.
Change-Id: I23df233cdf20c0a9a606fd9253e15a9b5482575a
Reviewed-on: https://go-review.googlesource.com/c/go/+/447715
Reviewed-by: David du Colombier <0intro@gmail.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/447875
Run-TryBot: David du Colombier <0intro@gmail.com>
When a function type is copied (e.g. for substituting type
parameters), we make copies of its parameter ir.Name nodes, so
they are not shared with the old function type. But currently a
blank (_) identifier is not copied but shared. The parameter
node's frame offset is assigned (in ABI analysis) and then used in
the concurrent backend. Shared node can cause a data race. Make a
new blank parameter node to avoid sharing. (Unified IR does already
not have this problem. This fixes non-unified-IR mode.)
Updates #55357.
Fixes#56359.
Change-Id: Ie27f08e5589ac7d5d3f0d0d5de1a21e4fd2765c9
Reviewed-on: https://go-review.googlesource.com/c/go/+/443158
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
(cherry picked from commit 4725c71b735143a138b24f2b0e055c717d8d69ca)
Reviewed-on: https://go-review.googlesource.com/c/go/+/445177
The existing implementation fails to convert the remainder
microseconds to nanoseconds. This causes sysmon to consume
much more cpu, and generate lots of context switches.
We can also do a little better here to avoid division by a
constant. I used go to determine the magic numbers.
Fixes#56396
Change-Id: I2e37ec218b9027efab6db4634eed1504c0c1b3c8
Reviewed-on: https://go-review.googlesource.com/c/go/+/444735
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/445156
This allows programs that want SHA1 support to call os.Setenv at startup
instead of insisting that users set the environment variable themselves.
For #41682.
Fixes#56436.
Fixes#56437.
Change-Id: Idcb96212a1d8c560e1dd8eaf7c80b6266f16431e
Reviewed-on: https://go-review.googlesource.com/c/go/+/445496
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-on: https://go-review.googlesource.com/c/go/+/445656
Check for and reject environment variables containing NULs.
The conventions for passing environment variables to subprocesses
cause most or all systems to interpret a NUL as a separator. The
syscall package rejects environment variables containing a NUL
on most systems, but erroneously did not do so on Windows. This
causes an environment variable such as "FOO=a\x00BAR=b" to be
interpreted as "FOO=a", "BAR=b".
Check for and reject NULs in environment variables passed to
syscall.StartProcess on Windows.
Add a redundant check to os/exec as extra insurance.
Updates #56284Fixes#56327
Fixes CVE-2022-41716
Change-Id: I2950e2b0cb14ebd26e5629be1521858f66a7d4ae
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1609434
Run-TryBot: Damien Neil <dneil@google.com>
Reviewed-by: Tatiana Bradley <tatianabradley@google.com>
Reviewed-by: Roland Shoemaker <bracewell@google.com>
TryBot-Result: Security TryBots <security-trybots@go-security-trybots.iam.gserviceaccount.com>
(cherry picked from commit 845accdebb2772c5344ed0c96df9910f3b02d741)
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1617552
Run-TryBot: Tatiana Bradley <tatianabradley@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/446915
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Tatiana Bradley <tatiana@golang.org>
Ms are allocated via standard heap allocation (`new(m)`), which means we
must keep them alive (i.e., reachable by the GC) until we are completely
done using them.
Ms are primarily reachable through runtime.allm. However, runtime.mexit
drops the M from allm fairly early, long before it is done using the M
structure. If that was the last reference to the M, it is now at risk of
being freed by the GC and used for some other allocation, leading to
memory corruption.
Ms with a Go-allocated stack coincidentally already keep a reference to
the M in sched.freem, so that the stack can be freed lazily. This
reference has the side effect of keeping this Ms reachable. However, Ms
with an OS stack skip this and are at risk of corruption.
Fix this lifetime by extending sched.freem use to all Ms, with the value
of mp.freeWait determining whether the stack needs to be freed or not.
For #56243.
Fixes#56308.
Change-Id: Ic0c01684775f5646970df507111c9abaac0ba52e
Reviewed-on: https://go-review.googlesource.com/c/go/+/443716
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
(cherry picked from commit e252dcf9d38ce9192bccacb7e33867cbfbd22b6c)
Reviewed-on: https://go-review.googlesource.com/c/go/+/443816
Reviewed-by: Austin Clements <austin@google.com>
Set a 128 MB limit on the amount of space used by []syntax.Inst
in the compiled form corresponding to a given regexp.
Also set a 128 MB limit on the rune storage in the *syntax.Regexp
tree itself.
Thanks to Adam Korczynski (ADA Logics) and OSS-Fuzz for reporting this issue.
Fixes CVE-2022-41715.
Updates #55949.
Fixes#55950.
Change-Id: Ia656baed81564436368cf950e1c5409752f28e1b
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1592136
TryBot-Result: Security TryBots <security-trybots@go-security-trybots.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Roland Shoemaker <bracewell@google.com>
Reviewed-by: Julie Qiu <julieqiu@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/438501
Run-TryBot: Carlos Amedee <carlos@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Set a 1MiB limit on special file blocks (PAX headers, GNU long names,
GNU link names), to avoid reading arbitrarily large amounts of data
into memory.
Thanks to Adam Korczynski (ADA Logics) and OSS-Fuzz for reporting
this issue.
Fixes CVE-2022-2879
Updates #54853Fixes#55925
Change-Id: I85136d6ff1e0af101a112190e027987ab4335680
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1565555
Reviewed-by: Tatiana Bradley <tatianabradley@google.com>
Run-TryBot: Roland Shoemaker <bracewell@google.com>
Reviewed-by: Roland Shoemaker <bracewell@google.com>
(cherry picked from commit 6ee768cef6b82adf7a90dcf367a1699ef694f3b2)
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1590622
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Julie Qiu <julieqiu@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/438500
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Carlos Amedee <carlos@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Query parameter smuggling occurs when a proxy's interpretation
of query parameters differs from that of a downstream server.
Change ReverseProxy to avoid forwarding ignored query parameters.
Remove unparsable query parameters from the outbound request
* if req.Form != nil after calling ReverseProxy.Director; and
* before calling ReverseProxy.Rewrite.
This change preserves the existing behavior of forwarding the
raw query untouched if a Director hook does not parse the query
by calling Request.ParseForm (possibly indirectly).
Fixes#55842
For #54663
For CVE-2022-2880
Change-Id: If1621f6b0e73a49d79059dae9e6b256e0ff18ca9
Reviewed-on: https://go-review.googlesource.com/c/go/+/432976
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Damien Neil <dneil@google.com>
(cherry picked from commit 7c84234142149bd24a4096c6cab691d3593f3431)
Reviewed-on: https://go-review.googlesource.com/c/go/+/433695
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Apparently the new darwin linker starts to emit a warning about
-no_pie deprecation. Maybe we want to switch to PIE by default.
For now, suppress the warning. This also makes it easier for
backporting to previous releases.
Fixes#55113.
Updates #55112, #54482.
Change-Id: I1a3b74c237a9d00ec3b030fc3a9940a31e5cd37e
Reviewed-on: https://go-review.googlesource.com/c/go/+/430937
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
(cherry picked from commit 706d84fca2b36fdf670a0d921e6a8a3b481eaa05)
Reviewed-on: https://go-review.googlesource.com/c/go/+/431518
Reviewed-by: Austin Clements <austin@google.com>
We added -pagezero_size in CL 72730, where it was intented for iOS.
The current code passes it only on macOS/AMD64 instead. It is not
really necessary there. Also, the new darwin linker starts to emit
a warning about deprecation of the flag. Stop passing it.
For #55113
Updates #54482, #55112.
Change-Id: If9db7a1645c37d4284e48f075856912df8d8c1a0
Reviewed-on: https://go-review.googlesource.com/c/go/+/430936
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
(cherry picked from commit 5231ba2f054f2ecb1387bad00b8745d6fe532ea4)
Reviewed-on: https://go-review.googlesource.com/c/go/+/431516
Reviewed-by: Austin Clements <austin@google.com>
Includes cases where the core type of the variadic parameter is
a slice or bytestring. Permits a client to create the signature
for various instantiations of append.
Fixes#55148.
Change-Id: I0f4983eb00c088cbe1d87954ee0b2df0ccc3bc49
Reviewed-on: https://go-review.googlesource.com/c/go/+/430455
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/431915
The type of the source and destination of a memmove call isn't
always accurate. It will always be a pointer (or an unsafe.Pointer), but
the base type might not be accurate. This comes about because multiple
copies of a pointer with different base types are coalesced into a single value.
In the failing example, the IData selector of the input argument is a
*[32]byte in one branch of the type switch, and a *[]byte in the other branch.
During the expand_calls pass both IDatas become just copies of the input
register. Those copies are deduped and an arbitrary one wins (in this case,
*[]byte is the unfortunate winner).
Generally an op v can rely on v.Type during rewrite rules. But relying
on v.Args[i].Type is discouraged.
Fixes#55151
Change-Id: I348fd9accf2058a87cd191eec01d39cda612f120
Reviewed-on: https://go-review.googlesource.com/c/go/+/431496
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
(cherry picked from commit e283473ebbebf4a80db166e7e852d03c5cff1a61)
Reviewed-on: https://go-review.googlesource.com/c/go/+/431918
ir.ClosureExpr implements ir.InitNode, so ir.InitExpr can prepend init
statements to it. However, CalleeEffects wasn't aware of this and
could cause the init statements to get dropped when inlining a call to
a closure.
This isn't an issue today, because we don't create closures with init
statements. But I ran into this within unified IR.
Easy and robust solution: just take advantage that ir.TakeInit can
handle any node.
Fixes#54918.
Change-Id: Ica05fbf6a8c5be4b11927daf84491a1140da5431
Reviewed-on: https://go-review.googlesource.com/c/go/+/422196
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/429897
Reviewed-by: Michael Knyszek <mknyszek@google.com>
On LR architectures, morestack (and morestack_noctxt) are called
with a special calling convention, where the caller doesn't save
LR on stack but passes it as a register, which morestack will save
to g.sched.lr. The stack unwinder currently doesn't understand it,
and would fail to unwind from it. morestack already writes SP (as
it switches stack), but morestack_noctxt (which tailcalls
morestack) doesn't. If a profiling signal lands right in
morestack_noctxt, the unwinder will try to unwind the stack and
go off, and possibly crash.
Marking morestack_noctxt SPWRITE stops the unwinding.
Ideally we could teach the unwinder about the special calling
convention, or change the calling convention to be less special
(so the unwinder doesn't need to fetch a register from the signal
context). This is a stop-gap solution, to stop the unwinder from
crashing.
Updates #54332.
Fixes#54674.
Change-Id: I75295f2e27ddcf05f1ea0b541aedcb9000ae7576
Reviewed-on: https://go-review.googlesource.com/c/go/+/425396
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
(cherry picked from commit e4be2ac79f3cc7219ae1cf8334463d11cae24e01)
Reviewed-on: https://go-review.googlesource.com/c/go/+/425616
R0 needs to be cleared at startup as it may not always be cleared
by the kernel on newer kernels.
Fixes#54664
Change-Id: Id7055699aaa8d8b193b7e3e784f075ce29ac3f1d
Reviewed-on: https://go-review.googlesource.com/c/go/+/424927
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/425369
Reviewed-by: Ian Lance Taylor <iant@google.com>
CL 327871 changes methodWrapper to always perform inlining after global
escape analysis. However, inlining the method may reveal closures, which
require walking all function bodies to decide whether to capture free
variables by value or by ref.
To fix it, just not doing inline if the method contains any closures.
Fixes#54725
Change-Id: I4b0255b86257cc6fe7e5fafbc545cc5cff9113e1
Reviewed-on: https://go-review.googlesource.com/c/go/+/426334
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/426159
This fixes a regression introduced when the "race" mode tag was moved to
the ToolTags field in CL 358539.
Fixes#54659
Updates #54468
Change-Id: I107771948a4fe9d743cc13d1c15f324212b08e03
GitHub-Last-Rev: d211e351ef3331f2c38b16d327d992a32ebbfe30
GitHub-Pull-Request: golang/go#54618
Reviewed-on: https://go-review.googlesource.com/c/go/+/425154
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
(cherry picked from commit 6ba2674ddc5373f261211ba5ebc38496dc660604)
Reviewed-on: https://go-review.googlesource.com/c/go/+/426435
Reviewed-by: Heschi Kreinick <heschi@google.com>
Ever since 'go build' was added (in CL 5483069), it has used an atexit
handler to clean up working directories.
CL 154109 introduced 'cc' command to the script test framework that
called Init on a builder once per invocation. Unfortunately, since
base.AtExit is unsynchronized, the Init added there caused any script
that invokes that command to be unsafe for concurrent use.
This change fixes the race by having the 'cc' command pass in its
working directory instead of allowing the Builder to allocate one.
Following modern Go best practices, it also replaces the in-place Init
method (which is prone to typestate and aliasing bugs) with a
NewBuilder constructor function.
Updates #54423.
Fixes#54636.
Change-Id: I8fc2127a7d877bb39a1174e398736bb51d03d4d2
Reviewed-on: https://go-review.googlesource.com/c/go/+/425205
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
(cherry picked from commit d5aa088d822bc8ef3ceb80c20184f40fcb9b8d2e)
Reviewed-on: https://go-review.googlesource.com/c/go/+/425208
