| Age | Commit message (Collapse) | Author |
|---|
|
finalizer call
The finalizer is called using reflectcall. When register ABI is
used, the finalizer's argument is passed in register(s). But the
frame size calculation does not include the spill slot. When the
argument actually spills, it may clobber the caller's stack frame.
This CL fixes it.
Updates #51457.
Fixes #51458.
Change-Id: Ibcc7507c518ba65c1c5a7759e5cab0ae3fc7efce
Reviewed-on: https://go-review.googlesource.com/c/go/+/389574
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
(cherry picked from commit 58804ea67a28c1d8e37ed548b685bc0c09638886)
Reviewed-on: https://go-review.googlesource.com/c/go/+/389794
|
|
Change-Id: I14f4da429cf8562c6cab99cd0cd4edfbc03f68e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/389736
Trust: Carlos Amedee <carlos@golang.org>
Run-TryBot: Carlos Amedee <carlos@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Alex Rakoczy <alex@golang.org>
|
|
go.mod file exists in a subdirectory for that version
Previous versions of the 'go' command would reject a pseudo-version
passed to 'go get' if that pseudo-version had a mismatched major
version and lacked a "+incompatible" suffix. However, they would
erroneously accept a version *with* a "+incompatible" suffix even if
the repo contained a vN/go.mod file for the same major version, and
would generate a "+incompatible" pseudo-version or version if the user
requested a tag, branch, or commit hash.
This change uniformly rejects "vN.…" without "+incompatible", and also
avoids resolving to "vN.…+incompatible", when vN/go.mod exists.
To maintain compatibility with existing go.mod files, it still accepts
"vN.…+incompatible" if the version is requested explicitly as such
and the repo root lacks a go.mod file.
Fixes #51332
Updates #51324
Updates #36438
Change-Id: I2b16150c73fc2abe4d0a1cd34cb1600635db7139
Reviewed-on: https://go-review.googlesource.com/c/go/+/387675
Trust: Bryan Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
(cherry picked from commit 5a9fc946b42cc987db41eabcfcbaffd2fb310d94)
Reviewed-on: https://go-review.googlesource.com/c/go/+/387922
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
|
|
RISCV64
Pointer comparison is lowered to the following on RISCV64
(EqPtr x y) => (SEQZ (SUB <x.Type> x y))
The difference of two pointers (the SUB) should not be pointer
type. Otherwise it can cause the GC to find a bad pointer.
Updates #51101.
Fixes #51199.
Change-Id: I7e73c2155c36ff403c032981a9aa9cccbfdf0f64
Reviewed-on: https://go-review.googlesource.com/c/go/+/385655
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
(cherry picked from commit 1ed30ca537a05b887f8479027b6363a03f957610)
Reviewed-on: https://go-review.googlesource.com/c/go/+/386474
|
|
There was an off-by-one error in the time histogram buckets calculation
that caused the linear sub-buckets distances to be off by 2x.
The fix was trivial, but in writing tests I realized there was a much
simpler way to express the calculation for the histogram buckets, and
took the opportunity to do that here. The new bucket calculation also
fixes the bug.
For #50732.
Fixes #50734.
Change-Id: Idae89986de1c415ee4e148f778e0e101ca003ade
Reviewed-on: https://go-review.googlesource.com/c/go/+/380094
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
(cherry picked from commit 2e9dcb508647dc473a37ecfa244d2bc4a1843ab4)
Reviewed-on: https://go-review.googlesource.com/c/go/+/384621
TryBot-Result: Gopher Robot <gobot@golang.org>
|
|
The existing value of 512 bytes as is specified by RFC 1035.
However, the WSL resolver reportedly sends larger packets without
setting the truncation bit, which breaks using the Go resolver.
For 1.18 and backports, just increase the accepted packet size.
This is what GNU glibc does (they use 65536 bytes).
For 1.19 we plan to use EDNS to set the accepted packet size.
That will give us more time to test whether that causes any problems.
No test because I'm not sure how to write one and it wouldn't really
be useful anyhow.
For #6464
For #21160
For #44135
For #51127
For #51153
Fixes #51162
Change-Id: I0243f274a06e010ebb714e138a65386086aecf17
Reviewed-on: https://go-review.googlesource.com/c/go/+/386015
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
(cherry picked from commit 6e82ff83cfbef78aa60706c1a7167a31c30e7ef9)
Reviewed-on: https://go-review.googlesource.com/c/go/+/386035
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
|
|
Parse
The regexp code assumes it can recurse over the structure of
a regexp safely. Go's growable stacks make that reasonable
for all plausible regexps, but implausible ones can reach the
“infinite recursion?” stack limit.
This CL limits the depth of any parsed regexp to 1000.
That is, the depth of the parse tree is required to be ≤ 1000.
Regexps that require deeper parse trees will return ErrInternalError.
A future CL will change the error to ErrInvalidDepth,
but using ErrInternalError for now avoids introducing new API
in point releases when this is backported.
Fixes #51112.
Fixes #51118.
Change-Id: I97d2cd82195946eb43a4ea8561f5b95f91fb14c5
Reviewed-on: https://go-review.googlesource.com/c/go/+/384616
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-on: https://go-review.googlesource.com/c/go/+/384854
TryBot-Result: Gopher Robot <gobot@golang.org>
|
|
Updates #48171
Fixes #51000
Change-Id: Ia2e1920c0938a1f8659935a4f725a7e5090ef2c0
Reviewed-on: https://go-review.googlesource.com/c/go/+/347034
Trust: Roland Shoemaker <roland@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
(cherry picked from commit 896df422a7cecbace10f5877beeeb1476b6061ae)
Reviewed-on: https://go-review.googlesource.com/c/go/+/382857
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
|
|
Change-Id: I760af1114e06bf408715e094d8d5b66c5aeb3e16
Reviewed-on: https://go-review.googlesource.com/c/go/+/384494
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Alex Rakoczy <alex@golang.org>
|
|
m.vdsoSP should be set to the SP of the caller of nanotime1,
instead of the SP of nanotime1 itself, which matches m.vdsoPC.
Otherwise the unmatched vdsoPC and vdsoSP would make the stack
trace look like recursive.
We already do it correctly on AMD64, 386, and RISCV64. This CL
fixes the rest.
Also incorporate CL 352509, skipping a flaky test.
Updates #47324, #50772.
Fixes #50781.
Change-Id: I98b6fcfbe9fc6bdd28b8fe2a1299b7c505371dd4
Reviewed-on: https://go-review.googlesource.com/c/go/+/337590
Trust: Cherry Mui <cherryyz@google.com>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
(cherry picked from commit 217507eb035933bac6c990844f0d71d6000fd339)
Reviewed-on: https://go-review.googlesource.com/c/go/+/380715
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
|
|
darwin
When building/using plugins on darwin, we need to use flat
namespace so the same symbol from the main executable and the
plugin can be resolved to the same address. Apparently, when using
flat namespace the dynamic linker can hang at forkExec when
resolving a lazy binding. Work around it by forcing early bindings.
Updates #38824.
Fixes #50246.
Change-Id: I983aa0a0960b15bf3f7871382e8231ee244655f4
Reviewed-on: https://go-review.googlesource.com/c/go/+/372798
Trust: Cherry Mui <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
(cherry picked from commit c5fee935bbb8f02406eb653cfed550593755a1a4)
Reviewed-on: https://go-review.googlesource.com/c/go/+/373094
|
|
invalid field elements
Updates #50974
Fixes #50978
Fixes CVE-2022-23806
Change-Id: I0201c2c88f13dd82910985a495973f1683af9259
Reviewed-on: https://go-review.googlesource.com/c/go/+/382854
Trust: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
Trust: Katie Hockman <katie@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
|
|
canonical versions
Since at least CL 121857, the conversion logic in
(*modfetch).codeRepo.Stat has had a short-circuit to use the version
requested by the caller if it successfully resolves and is already
canonical.
However, we should not use that version if it refers to a branch
instead of a tag, because branches (unlike tags) usually do not refer
to a single, stable release: a branch named "v1.0.0" may be for the
development of the v1.0.0 release, or for the development of patches
based on v1.0.0, but only one commit (perhaps at the end of that
branch — but possibly not even written yet!) can be that specific
version.
We already have some logic to prefer tags that are semver-equivalent
to the version requested by the caller. That more general case
suffices for exact equality too — so we can eliminate the
special-case, fixing the bug and (happily!) also somewhat simplifying
the code.
Updates #35671
Fixes #50687
Fixes CVE-2022-23773
Change-Id: I2fd290190b8a99a580deec7e26d15659b58a50b0
Reviewed-on: https://go-review.googlesource.com/c/go/+/378400
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
(cherry picked from commit fa4d9b8e2bc2612960c80474fca83a4c85a974eb)
Reviewed-on: https://go-review.googlesource.com/c/go/+/382835
|
|
transformations
These can go wrong when one of the operands is the minimum integer value.
Fixes #50867.
Change-Id: I238fe284f60c7ee5aeb9dc9a18e8b1578cdb77d0
Reviewed-on: https://go-review.googlesource.com/c/go/+/381318
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
(cherry picked from commit b7b44b3173f151a2313da7072afd25de80511605)
Reviewed-on: https://go-review.googlesource.com/c/go/+/381474
Run-TryBot: Cherry Mui <cherryyz@google.com>
|
|
register on MIPS64
For an extension operation like MOVWreg, if the operand is already
extended, we optimize the second extension out. Usually a LoadReg
of a proper type would come already extended, as a MOVW/MOVWU etc.
instruction does. But for a LoadReg to a floating point register,
the instruction does not do the extension. So we cannot elide the
extension.
Updates #50671.
Fixes #50683.
Change-Id: Id8991df78d5acdecd3fd6138c558428cbd5f6ba3
Reviewed-on: https://go-review.googlesource.com/c/go/+/379236
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
(cherry picked from commit d93ff73ae207763871bee38590242be968b2e743)
Reviewed-on: https://go-review.googlesource.com/c/go/+/379514
|
|
loop for span6
Updates #49716.
Fixes #50942.
Change-Id: I7ed73f874c2ee1ee3f31c9c4428ed484167ca803
Reviewed-on: https://go-review.googlesource.com/c/go/+/366094
Reviewed-by: Cherry Mui <cherryyz@google.com>
Trust: Heschi Kreinick <heschi@google.com>
(cherry picked from commit 14f2b2a4c55b707828be2890b8c750cb849203f6)
Reviewed-on: https://go-review.googlesource.com/c/go/+/383214
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Alex Rakoczy <alex@golang.org>
|
|
Mercurial was deprecated as of July 1, 2020 as per https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket
Fixes #50812.
Updates #50810.
Change-Id: I0d40f84aaa393905cae7c4bed8919b15de9a5f6d
Reviewed-on: https://go-review.googlesource.com/c/go/+/371720
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Trust: Bryan Mills <bcmills@google.com>
(cherry picked from commit 5b1b80beb1a2a9a353738e80777d1e25cfdfa095)
Reviewed-on: https://go-review.googlesource.com/c/go/+/380996
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
Adds the same logic used in debug/elf to load DWARF5 sections.
For #49590
Fixes #50722
Change-Id: Iee05b9927a6f521842b330eab8942ade3fc2bd86
Reviewed-on: https://go-review.googlesource.com/c/go/+/363895
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Than McIntosh <thanm@google.com>
(cherry picked from commit 6c36c332fefdd433cfe6e6468a2542fc310e9f8a)
Reviewed-on: https://go-review.googlesource.com/c/go/+/379914
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Alessandro Arzilli <alessandro.arzilli@gmail.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
|
|
Credit to rsc@ for the original patch.
Thanks to the OSS-Fuzz project for discovering this
issue and to Emmanuel Odeke (@odeke_et) for reporting it.
Updates #50699
Fixes #50701
Fixes CVE-2022-23772
Change-Id: I590395a3d55689625390cf1e58f5f40623b26ee5
Reviewed-on: https://go-review.googlesource.com/c/go/+/379537
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Julie Qiu <julie@golang.org>
(cherry picked from commit ad345c265916bbf6c646865e4642eafce6d39e78)
Reviewed-on: https://go-review.googlesource.com/c/go/+/381336
Reviewed-by: Filippo Valsorda <filippo@golang.org>
|
|
certificate
Upgrade the test certificate from RSA 1024 (not FIPS-approved)
to RSA 2048 (FIPS-approved), allowing tests to pass when
the dev.boringcrypto branch FIPS-only mode is enabled.
For #48674.
Fixes #50586.
Change-Id: I613d2f8d0207bf3683fd0df256bf0167604996c5
Reviewed-on: https://go-review.googlesource.com/c/go/+/353869
Trust: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
(cherry picked from commit 90860e0c3110ac5898dfe8e0e0fafd0aea8d979a)
Reviewed-on: https://go-review.googlesource.com/c/go/+/380995
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
|
|
Change-Id: I66a51a8fb3405395c066db37195e7e2a5c44a2d6
Reviewed-on: https://go-review.googlesource.com/c/go/+/375975
Trust: Carlos Amedee <carlos@golang.org>
Run-TryBot: Carlos Amedee <carlos@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
|
|
Pull in approved backports to golang.org/x/net/http2:
21a9c9c http2: prioritize RST_STREAM frames in random write scheduler
By doing:
$ go get -d golang.org/x/net@internal-branch.go1.17-vendor
$ go mod tidy
$ go mod vendor
$ go generate -run=bundle std
Fixes #49921
Change-Id: I04739a30d84a8ae449374eca8bb11c7d2d215ad9
Reviewed-on: https://go-review.googlesource.com/c/go/+/375814
Run-TryBot: Carlos Amedee <carlos@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Trust: Carlos Amedee <carlos@golang.org>
|
|
For #50295
Fixes #50297
Change-Id: If55ebcd5f2af724da7c9c744458a56d21a7ddde7
Reviewed-on: https://go-review.googlesource.com/c/go/+/373734
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
(cherry picked from commit cfb0cc355233d4367b188b23a3bc143985a28b8c)
Reviewed-on: https://go-review.googlesource.com/c/go/+/374194
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
|
|
incremental pagealloc
In iOS <14, the address space is strictly limited to 8 GiB, or 33 bits.
As a result, the page allocator also assumes all heap memory lives in
this region. This is especially necessary because the page allocator has
a PROT_NONE mapping proportional to the size of the usable address
space, so this keeps that mapping very small.
However starting with iOS 14, this restriction is relaxed, and mmap may
start returning addresses outside of the <14 range. Today this means
that in iOS 14 and later, users experience an error in the page
allocator when a heap arena is mapped outside of the old range.
This change increases the ios/arm64 heapAddrBits to 40 while
simultaneously making ios/arm64 use the 64-bit pagealloc implementation
(with reservations and incremental mapping) to accommodate both iOS
versions <14 and 14+.
Once iOS <14 is deprecated, we can remove these exceptions and treat
ios/arm64 like any other arm64 platform.
This change also makes the BaseChunkIdx expression a little bit easier
to read, while we're here.
For #46860.
Fixes #48116.
Change-Id: I13865f799777739109585f14f1cc49d6d57e096b
Reviewed-on: https://go-review.googlesource.com/c/go/+/344401
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Austin Clements <austin@google.com>
(cherry picked from commit af368da0b137116faba81ca249a8d964297e6e45)
Reviewed-on: https://go-review.googlesource.com/c/go/+/369737
|
|
macOS 12 malloc reserved address
On macOS 12 a new malloc implementation (nano) is used by default,
and apparently it reserves address range
0x600000000000-0x600020000000, which conflicts with the address
range that TSAN uses for Go. Work around the issue by changing the
address range slightly.
The actual change is made on LLVM at https://reviews.llvm.org/D114825 .
This CL includes syso's built with the patch applied.
The syso in 1.17 was identical to the syso before the equivalent fix
on the main branch, so the back-ported syso is identical to the fixed
syso on the main branch.
Fixes #50073.
Updates #49138.
Change-Id: I7b367d6e042b0db39a691c71601c98e4f8728a70
Reviewed-on: https://go-review.googlesource.com/c/go/+/367916
Trust: Cherry Mui <cherryyz@google.com>
Reviewed-by: Austin Clements <austin@google.com>
(cherry picked from commit 5f6552018d1ec920c3ca3d459691528f48363c3c)
Reviewed-on: https://go-review.googlesource.com/c/go/+/370697
|
|
when has opendefers
The openDeferRecord always insert vardef/varlive pairs into the entry block, it may destroy the mem chain when LECall's args are writing into the same block. So create a new block before that happens.
Fixes #49413
Change-Id: Ibda6c4a45d960dd412a641f5e02276f663c80785
Reviewed-on: https://go-review.googlesource.com/c/go/+/361410
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Alberto Donizetti <alb.donizetti@gmail.com>
Trust: Than McIntosh <thanm@google.com>
Reviewed-by: David Chase <drchase@google.com>
(cherry picked from commit 4f083c7dcf6ace3e837b337e10cf2f4e3160677e)
Reviewed-on: https://go-review.googlesource.com/c/go/+/362054
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
|
|
in Call
When register ABI is used, reflect.Value.Call prepares the call
arguments in a memory representation of the argument registers.
It has special handling to keep the pointers in arguments live.
Currently, this handles pointer-typed arguments. But when an
argument is an aggregate-type that contains pointers and passed
in registers, it currently doesn't keep the pointers live. Do
so in this CL.
Fixes #49961
Change-Id: I9264a8767e2a2c48573f6047144759b845dcf480
Reviewed-on: https://go-review.googlesource.com/c/go/+/369098
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
|
|
cryptobyte fix
Updates #49678
Fixes #50165
Change-Id: I47dd959a787180a67856e60dfa6eba3ddd045972
Reviewed-on: https://go-review.googlesource.com/c/go/+/373361
Trust: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Julie Qiu <julie@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
|
|
Change-Id: Ief6fb9e836c1d40ece56868d65ebf65f74e65665
Reviewed-on: https://go-review.googlesource.com/c/go/+/370555
Trust: Alex Rakoczy <alex@golang.org>
Run-TryBot: Alex Rakoczy <alex@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
|
|
Pull in security fix
84cba54 http2: cap the size of the server's canonical header cache
Updates #50058
Fixes CVE-2021-44716
Change-Id: Ia89e3d22a173c6cb83f03608d5186fcd08f2956c
Reviewed-on: https://go-review.googlesource.com/c/go/+/370574
Trust: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Alex Rakoczy <alex@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
|
|
Generally speaking Go functions make no guarantees
about what has happened to result parameters on error,
and Pipe is no exception: callers should avoid looking at
p if Pipe returns an error.
However, we had a bug in which ForkExec was using the
content of p after a failed Pipe, and others may too.
As a robustness fix, make Pipe avoid writing to p on failure.
Updates #50057
Change-Id: Ie8955025dbd20702fabadc9bbe1d1a5ac0f36305
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1291271
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/370535
Trust: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Alex Rakoczy <alex@golang.org>
|
|
Pipe (and therefore forkLockPipe) does not make any guarantees
about the state of p after a failed Pipe(p). Avoid that assumption
and the too-clever goto, so that we don't accidentally Close a real fd
if the failed pipe leaves p[0] or p[1] set >= 0.
Updates #50057
Fixes CVE-2021-44717
Change-Id: Iff8e19a6efbba0c73cc8b13ecfae381c87600bb4
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1291270
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/370534
Trust: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Alex Rakoczy <alex@golang.org>
|
|
darwin/arm64 builder
Repeat of CL 321349 for macOS 12. We won't need to do this again -- the
test is passing at tip.
Updates #46239.
Change-Id: Ib279ada443ee03eb8e70fde4bbfba65ce0f6322e
Reviewed-on: https://go-review.googlesource.com/c/go/+/369748
Trust: Heschi Kreinick <heschi@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
|
|
Change-Id: I11748377b7a35bd38b52e6f81093cc210f6d2857
Reviewed-on: https://go-review.googlesource.com/c/go/+/368695
Trust: Heschi Kreinick <heschi@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
|
|
struct/array
This is backport of CL 3651594, with the test from CL 360057.
CL 360057 fixed missing update source type in storeArgOrLoad. However,
we should only update the type when processing struct/array. If we
update the type right before calling storeArgOrLoad, we may generate a
value with invalid type, e.g, OpStructSelect with non-struct type.
Fixes #49392
Change-Id: Ib7e10f72f818880f550aae5c9f653db463ce29b0
Reviewed-on: https://go-review.googlesource.com/c/go/+/361594
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/361596
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
|
|
Pull in approved backports to golang.org/x/net/http2:
85e122b net/http2: Fix handling of expect continue
1dc0aec http2: don't count aborted streams as active in tests
e973a42 ipv6: OpenBSD does not appear to support multicast loopback
9592dd5 http2: avoid busy loop when ResponseHeaderTimeout is set
94fb2bc http2: avoid spurious RoundTrip error when server closes and resets stream
e108c19 http2: close conns after use when req.Close is set
By doing:
$ go get -d golang.org/x/net@internal-branch.go1.17-vendor
go: upgraded golang.org/x/net v0.0.0-20211101194204-95aca89e93de => v0.0.0-20211201233630-85e122b1a9b3
$ go mod tidy
$ go mod vendor
$ go generate -run=bundle std
Fixes #49561.
Fixes #49624.
Fixes #49662.
Fixes #49905.
Fixes #49909.
Fixes #49911.
Change-Id: Ia8f432bd3ea77d24e63d46c8ed2ac8d275406b52
Reviewed-on: https://go-review.googlesource.com/c/go/+/368574
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
|
|
This is a partial port of CL 354329 from types2 to go/types.
It contains an adjustment to type.go to deal with possibly
invalid type bounds.
Fixes #48825.
For #48819.
Change-Id: I9efdcdbfa6432f3cee64d924a4c67ecc6793cf86
Reviewed-on: https://go-review.googlesource.com/c/go/+/354349
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/368456
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
|
|
responses
Server handlers may set a "Transfer-Encoding: identity" header on
responses to disable chunking, but this header should not be sent
on the wire.
For #49194.
Fixes #49568.
Change-Id: I46a9e3b8ff9d93edd7d1c34d264fc309fa322ad5
Reviewed-on: https://go-review.googlesource.com/c/go/+/359176
Trust: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit b69b2f63d65609b400b4a40ae01e4a48638f050f)
Reviewed-on: https://go-review.googlesource.com/c/go/+/368087
Reviewed-by: Michael Knyszek <mknyszek@google.com>
|
|
body read
When sending a Request with a non-context deadline, we create a
context with a timeout. This context is canceled when closing the
response body, and also if a read from the response body returns
an error (including io.EOF).
Cancelling the context in Response.Body.Read interferes with the
HTTP/2 client cleaning up after a request is completed, and is
unnecessary: The user should always close the body, the impact
from not canceling the context is minor (the context timer leaks
until it fires).
Fixes #49559.
For #49366.
Change-Id: Ieaed866116916261d9079f71d8fea7a7b303b8fb
Reviewed-on: https://go-review.googlesource.com/c/go/+/361919
Trust: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit 76fbd6167364fb98e3ebe946cfc16b5b84d4240e)
Reviewed-on: https://go-review.googlesource.com/c/go/+/368085
Reviewed-by: Michael Knyszek <mknyszek@google.com>
|
|
to prevent GC
When syscall's DLL.FindProc calls into syscall_getprocaddress with a
byte slice pointer, we need to keep those bytes alive. Otherwise the GC
will collect the allocation, and we wind up calling `GetProcAddress` on
garbage, which showed up as various flakes in the builders. It turns out
that this problem extends to many uses of //go:cgo_unsafe_args
throughout, on all platforms. So this patch fixes the issue by keeping
non-integer pointer arguments alive through their invocation in
//go:cgo_unsafe_args functions.
Fixes #49868.
Updates #49731.
Change-Id: I93e4fbc2e8e210cb3fc53149708758bb33f2f9c7
Reviewed-on: https://go-review.googlesource.com/c/go/+/368355
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
|
|
to a zone transition
The old implement passed start - 1 or end in func lookup to adjust the offset.But if the time is close to the last zoneTrans, like the issue, testcase and comment, the "start" from lookup will be omega. It can't be adjusted correctly.
Fixes #49407
Change-Id: Ibaf82dc4db6d5dd3279796f003d2b19c38a26341
Reviewed-on: https://go-review.googlesource.com/c/go/+/360616
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Robert Findley <rfindley@google.com>
(cherry picked from commit 90462dfc3aa99649de90bb587af56a9cb0214665)
Reviewed-on: https://go-review.googlesource.com/c/go/+/361955
Trust: Dmitri Shuralyov <dmitshur@golang.org>
|
|
dropped
When an OAS node is converted to an OSELRECV2 node in tcSelect(), the
possible DCL node in the Init field was being dropped, since a
completely new node was being created and the Init field was not set. I
don't expect n.Init() to be set for the ORECV case, but the code now
deals with that too.
Fixed bug in both tcSelect() and transformSelect().
Cherry-picked from https://go-review.googlesource.com/c/go/+/348569
Fixes #49511
Change-Id: Id5b736daa8e90afda88aaa3769dde801db294c0d
Reviewed-on: https://go-review.googlesource.com/c/go/+/363664
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
|
|
remainder
A code comment on amd64 for windows and plan9 contained a snippet for
splitting apart the sec and nsec components of a unix timestamp, with
produced assembly below, which was then cleaned up by hand. When arm64
was ported, that code snippet in the comment went through the compiler
to produce some code that was then pasted and cleaned up. Unfortunately,
the comment had a typo in it, containing 8 zeros instead of 9.
This resulted in the constant used in the assembly being wrong, spotted
by @bufflig's eagle eyes. So, this commit fixes the comment on all three
platforms, and the assembly on windows/arm64.
Updates #48072.
Fixes #49369.
Change-Id: I786fe89147328b0d25544f52c927ddfdb9f6f1cf
Reviewed-on: https://go-review.googlesource.com/c/go/+/361474
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Patrik Nyblom <pnyb@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-on: https://go-review.googlesource.com/c/go/+/361476
|
|
instruction or issue barrier
On 64-bit, this is more efficient, and on ARM64, this prevents the time
from moving backwards due to the weaker memory model. On ARM32 due to
the weaker memory model, we issue a memory barrier.
Updates #48072.
Updates #49369.
Change-Id: If4695716c3039d8af14e14808af217f5c99fc93a
Reviewed-on: https://go-review.googlesource.com/c/go/+/361057
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/361475
Reviewed-by: Patrik Nyblom <pnyb@google.com>
|
|
removePred and removeArg do different things. removePred moves the last
predecessor to index k, whereas removeArg slides all the args k or
greater down by 1 index.
Kind of unfortunate different behavior in things named similarly.
Fixes #49129
Change-Id: I9ae409bdac744e713f4c121f948e43db6fdc8542
Reviewed-on: https://go-review.googlesource.com/c/go/+/358117
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
(cherry picked from commit 8dbf3e9393400d72d313e5616c88873e07692c70)
Reviewed-on: https://go-review.googlesource.com/c/go/+/358118
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
|
|
script tests
For #49138
Updates #49723
Fixes #49729
Change-Id: Ia93130fdc042a1e2107be95cccd7e7eeaa909a87
Reviewed-on: https://go-review.googlesource.com/c/go/+/366254
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
(cherry picked from commit 189b4a2f428be7264db76e5275c96d98b847383b)
Reviewed-on: https://go-review.googlesource.com/c/go/+/366257
TryBot-Result: Go Bot <gobot@golang.org>
|
|
address relocations on ARM64 PE
On ARM64 PE, when external linking, the PE relocation does not
have an explicit addend, and instead has the addend encoded in
the instruction or data. An instruction (e.g. ADRP, ADD) has
limited width for the addend, so when the addend is large we use
a label symbol, which points to the middle of the original target
symbol, and a smaller addend. But for an absolute address
relocation in the data section, we have the full width to encode
the addend and we should not use the label symbol. Also, since we
do not adjust the addend in the data, using the label symbol will
actually make it point to the wrong address. E.g for an R_ADDR
relocation targeting x+0x123456, we should emit 0x123456 in the
data with an IMAGE_REL_ARM64_ADDR64 relocation pointing to x,
whereas the current code emits 0x123456 in the data with an
IMAGE_REL_ARM64_ADDR64 relocation pointing to the label symbol
x+1MB, so it will actually be resolved to x+0x223456. This CL
fixes this.
Fixes #49479
Change-Id: I64e02b56f1d792f8c20ca61b78623ef5c3e34d7e
Reviewed-on: https://go-review.googlesource.com/c/go/+/360895
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
(cherry picked from commit 988efd58197205060ace508d29984fbab6eb3840)
Reviewed-on: https://go-review.googlesource.com/c/go/+/363014
Run-TryBot: Carlos Amedee <carlos@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
|
|
https://github.com/googleapis/google-cloud-go has changed the default
branch from master to main, causing mod_get_direct failed on longtest.
Change-Id: I8fe0356b2ff532d1fdedbcb1e1832d7335babaa0
Reviewed-on: https://go-review.googlesource.com/c/go/+/361965
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
(cherry picked from commit b7529c3617a64ed5d1e2a6c7a9366d4a4988a38d)
Reviewed-on: https://go-review.googlesource.com/c/go/+/362535
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
|
|
Change-Id: Iaf0b58846a9641525f43f4dc64962c13c0c7e8e3
Reviewed-on: https://go-review.googlesource.com/c/go/+/361200
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
|
|
Previously, opening a zip with (*Reader).Open could result in a panic if
the zip contained a file whose name was exclusively made up of slash
characters or ".." path elements.
Open could also panic if passed the empty string directly as an argument.
Now, any files in the zip whose name could not be made valid for
fs.FS.Open will be skipped, and no longer added to the fs.FS file list,
although they are still accessible through (*Reader).File.
Note that it was already the case that a file could be accessible from
(*Reader).Open with a name different from the one in (*Reader).File, as
the former is the cleaned name, while the latter is the original one.
Finally, made the actual panic site robust as a defense-in-depth measure.
Fixes CVE-2021-41772
Fixes #48252
Updates #48085
Co-authored-by: Filippo Valsorda <filippo@golang.org>
Change-Id: I6271a3f2892e7746f52e213b8eba9a1bba974678
Reviewed-on: https://go-review.googlesource.com/c/go/+/349770
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Trust: Katie Hockman <katie@golang.org>
Trust: Julie Qiu <julie@golang.org>
(cherry picked from commit b24687394b55a93449e2be4e6892ead58ea9a10f)
Reviewed-on: https://go-review.googlesource.com/c/go/+/360859
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
|
