| Age | Commit message (Collapse) | Author |
|---|
|
Change-Id: Iad8c5261b54d0a160ec6037d877b8655535149fa
Reviewed-on: https://go-review.googlesource.com/c/go/+/474038
Auto-Submit: Carlos Amedee <carlos@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
TryBot-Bypass: Carlos Amedee <carlos@golang.org>
Auto-Submit: Gopher Robot <gobot@golang.org>
Run-TryBot: Gopher Robot <gobot@golang.org>
|
|
Convert TestUnknownAuthorityError to use subtests, avoiding continuing
the test after an unrecoverable failure.
Skip TestIssue51759 on pre-macOS 11 builders, which don't enforce the
behavior we were testing for. Also only enable the test on builders.
Updates #58791
Updates #58812
Fixes #58810
Change-Id: I4e3e5bc371aa139d38052184c8232f8cb564138f
Reviewed-on: https://go-review.googlesource.com/c/go/+/472496
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
(cherry picked from commit cf3d0655f8ca2de555549f6e8a91bf8654da7e6c)
Reviewed-on: https://go-review.googlesource.com/c/go/+/472617
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
|
|
intermediate handling
On Windows, replace tests which rely on a root that expired last year.
On Darwin fix an test which wasn't testing the expected behavior, and
fix the behavior which was broken.
Updates #58791
Fixes #58810
Change-Id: I771175b9e123b8bb0e4efdf58cc2bb93aa94fbae
Reviewed-on: https://go-review.googlesource.com/c/go/+/472295
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Roland Shoemaker <roland@golang.org>
(cherry picked from commit bb8f9a6ae66d742cb67b4ad444179905a537de00)
Reviewed-on: https://go-review.googlesource.com/c/go/+/472615
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
|
|
Windows
This cherry-pick CL 471335 without using unsafe.{Add,Slice}.
Fixes #58773
Change-Id: Ifa5c059ed5e358ed98aee7e83b95dd1806b535f7
Reviewed-on: https://go-review.googlesource.com/c/go/+/471335
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/471935
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
|
|
This test is flaky, apparently due to a typo'd operator in CL 21447
that causes it to compare “same port OR IP” instead of
“same port AND IP”.
If we merely fixed the comparison, the test would hopefully stop being
flaky itself, but we would still be left with another problem:
repeatedly dialing a port that we believe to be unused can interfere
with other tests, which may open the previously-unused port and then
attempt a single Dial and expect it to succeed. Arbitrary other Dial
calls for that port may cause the wrong connection to be accepted,
leading to spurious test failures.
Moreover, the test can be extremely expensive for the amount of data
we hope to get from it, depending on the system's port-reuse
algorithms and dial implementations. It is already scaled back by up
to 1000x on a huge number of platforms due to latency, and may even be
ineffective on those platforms because of the arbitrary 1ms Dial
timeout. And the incremental value from it is quite low, too: it tests
the workaround for what is arguably a bug in the Linux kernel, which
ought to be fixed (and tested) upstream instead of worked around in
every open-source project that dials local ports.
Instead of trying to deflake this test, let's just get rid of it.
Updates #18290.
Fixes #58716.
Change-Id: I8a58b93d67916a33741c9ab29ef99c49c46b32c4
Reviewed-on: https://go-review.googlesource.com/c/go/+/460657
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
(cherry picked from commit e08642cae18460778ba3f7808c91cbf6d9ee9f67)
Reviewed-on: https://go-review.googlesource.com/c/go/+/471156
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
|
|
duff routines
This patch provides a fix for a problem linking large arm32 binaries
with external linking, specifically R_CALLARM relocations against
runtime.duff* routines being flagged by the external linker as not
reaching.
What appears to be happening in the bug in question is that the Go
linker and the external linker are using slightly different recipes to
decide whether a given R_CALLARM relocation will "fit" (e.g. will not
require a trampoline). The Go linker is taking into account the addend
on the call reloc (which for calls to runtime.duffcopy or
runtime.duffzero is nonzero), whereas the external linker appears to
be ignoring the addend.
Example to illustrate:
Addr Size Func
----- ----- -----
...
XYZ 1024 runtime.duffcopy
...
ABC ... mypackge.MyFunc
+ R0: R_CALLARM o=8 a=848 tgt=runtime.duffcopy<0>
Let's say that the distance between ABC (start address of
runtime.duffcopy) and XYZ (start of MyFunc) is just over the
architected 24-bit maximum displacement for an R_CALLARM (let's say
that ABC-XYZ is just over the architected limit by some small value,
say 36). Because we're calling into runtime.duffcopy at offset 848,
however, the relocation does in fact fit, but if the external linker
isn't taking into account the addend (assuming that all calls target
the first instruction of the called routine), then we'll get a
"doesn't fit" error from the linker.
To work around this problem, revise the ARM trampoline generation code
in the Go linker that computes the trampoline threshold to ignore the
addend on R_CALLARM relocations, so as to harmonize the two linkers.
Fixes #58502.
Updates #58428.
Updates #58425.
Change-Id: I56e580c05b7b47bbe8edf5532a1770bbd700fbe5
Reviewed-on: https://go-review.googlesource.com/c/go/+/469275
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
(cherry picked from commit 0b5affb193ed559f2cb646e0324827f261e2e767)
Reviewed-on: https://go-review.googlesource.com/c/go/+/471598
|
|
Unlike the rest of nistec, the P-256 assembly doesn't use complete
addition formulas, meaning that p256PointAdd[Affine]Asm won't return the
correct value if the two inputs are equal.
This was (undocumentedly) ignored in the scalar multiplication loops
because as long as the input point is not the identity and the scalar is
lower than the order of the group, the addition inputs can't be the same.
As part of the math/big rewrite, we went however from always reducing
the scalar to only checking its length, under the incorrect assumption
that the scalar multiplication loop didn't require reduction.
Added a reduction, and while at it added it in P256OrdInverse, too, to
enforce a universal reduction invariant on p256OrdElement values.
Note that if the input point is the infinity, the code currently still
relies on undefined behavior, but that's easily tested to behave
acceptably, and will be addressed in a future CL.
Updates #58647
Fixes #58719
Fixes CVE-2023-24532
(Filed with the "safe APIs like complete addition formulas are good" dept.)
Change-Id: I7b2c75238440e6852be2710fad66ff1fdc4e2b24
Reviewed-on: https://go-review.googlesource.com/c/go/+/471255
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
(cherry picked from commit 203e59ad41bd288e1d92b6f617c2f55e70d3c8e3)
Reviewed-on: https://go-review.googlesource.com/c/go/+/471696
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Roland Shoemaker <roland@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
|
|
The sweep assist computation is intentionally racy for performance,
since the specifics of sweep assist aren't super sensitive to error.
However, if overflow occurs when computing the live heap delta, we can
end up with a massive sweep target that causes the sweep assist to sweep
until sweep termination, causing severe latency issues. In fact, because
heapLive doesn't always increase monotonically then anything that
flushes mcaches will cause _all_ allocating goroutines to inevitably get
stuck in sweeping.
Consider the following scenario:
1. SetGCPercent is called, updating sweepHeapLiveBasis to heapLive.
2. Very shortly after, ReadMemStats is called, flushing mcaches and
decreasing heapLive below the value sweepHeapLiveBasis was set to.
3. Every allocating goroutine goes to refill its mcache, calls into
deductSweepCredit for sweep assist, and gets stuck sweeping until
the sweep phase ends.
Fix this by just checking for overflow in the delta live heap calculation
and if it would overflow, pick a small delta live heap. This probably
means that no sweeping will happen at all, but that's OK. This is a
transient state and the runtime will recover as soon as heapLive
increases again.
Note that deductSweepCredit doesn't check overflow on other operations
but that's OK: those operations are signed and extremely unlikely to
overflow. The subtraction targeted by this CL is only a problem because
it's unsigned. An alternative fix would be to make the operation signed,
but being explicit about the overflow situation seems worthwhile.
For #57523.
Fixes #58535.
Change-Id: Ib18f71f53468e913548aac6e5358830c72ef0215
Reviewed-on: https://go-review.googlesource.com/c/go/+/468376
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
|
|
These functions are linked using go:linkname, but do not match the
original declarations. This change brings these in sync.
For #58441.
Change-Id: I16651304c3dba2f9897c2c42e30555d2f7805c2a
Reviewed-on: https://go-review.googlesource.com/c/go/+/466615
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Michael Pratt <mpratt@google.com>
(cherry picked from commit 8fb9565832e6dbacaaa057ffabc251a9341f8d23)
Reviewed-on: https://go-review.googlesource.com/c/go/+/466858
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
|
|
Update golang.org/x/net to the tip of internal-branch.go1.19-vendor to
include CL 468335.
The contents of that CL were already merged into this branch in CL
468118, so this CL just brings go.mod back in line to matching the
actual vendored content.
For #58355
For #57855
Change-Id: Ie952744a5b2249f0c05afb7f86bebf872734b09a
Reviewed-on: https://go-review.googlesource.com/c/go/+/468303
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
|
|
Change-Id: Iaafff862e746e7c81a6df9ca9b7b6179efe1172e
Reviewed-on: https://go-review.googlesource.com/c/go/+/468237
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Auto-Submit: Gopher Robot <gobot@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
|
|
Disable cmd/internal/moddeps test, since this update includes PRIVATE
track fixes.
Fixes CVE-2022-41723
Fixes #58355
Updates #57855
Change-Id: Ie870562a6f6e44e4e8f57db6a0dde1a41a2b090c
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1728939
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Julie Qiu <julieqiu@google.com>
Reviewed-by: Tatiana Bradley <tatianabradley@google.com>
Run-TryBot: Roland Shoemaker <bracewell@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/468118
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
|
|
Message marshalling makes use of BytesOrPanic a lot, under the
assumption that it will never panic. This assumption was incorrect, and
specifically crafted handshakes could trigger panics. Rather than just
surgically replacing the usages of BytesOrPanic in paths that could
panic, replace all usages of it with proper error returns in case there
are other ways of triggering panics which we didn't find.
In one specific case, the tree routed by expandLabel, we replace the
usage of BytesOrPanic, but retain a panic. This function already
explicitly panicked elsewhere, and returning an error from it becomes
rather painful because it requires changing a large number of APIs.
The marshalling is unlikely to ever panic, as the inputs are all either
fixed length, or already limited to the sizes required. If it were to
panic, it'd likely only be during development. A close inspection shows
no paths for a user to cause a panic currently.
This patches ends up being rather large, since it requires routing
errors back through functions which previously had no error returns.
Where possible I've tried to use helpers that reduce the verbosity
of frequently repeated stanzas, and to make the diffs as minimal as
possible.
Thanks to Marten Seemann for reporting this issue.
Updates #58001
Fixes #58358
Fixes CVE-2022-41724
Change-Id: Ieb55867ef0a3e1e867b33f09421932510cb58851
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1679436
Reviewed-by: Julie Qiu <julieqiu@google.com>
TryBot-Result: Security TryBots <security-trybots@go-security-trybots.iam.gserviceaccount.com>
Run-TryBot: Roland Shoemaker <bracewell@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
(cherry picked from commit 0f3a44ad7b41cc89efdfad25278953e17d9c1e04)
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1728204
Reviewed-by: Tatiana Bradley <tatianabradley@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/468117
Auto-Submit: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
|
|
ReadForm
Reader.ReadForm is documented as storing "up to maxMemory bytes + 10MB"
in memory. Parsed forms can consume substantially more memory than
this limit, since ReadForm does not account for map entry overhead
and MIME headers.
In addition, while the amount of disk memory consumed by ReadForm can
be constrained by limiting the size of the parsed input, ReadForm will
create one temporary file per form part stored on disk, potentially
consuming a large number of inodes.
Update ReadForm's memory accounting to include part names,
MIME headers, and map entry overhead.
Update ReadForm to store all on-disk file parts in a single
temporary file.
Files returned by FileHeader.Open are documented as having a concrete
type of *os.File when a file is stored on disk. The change to use a
single temporary file for all parts means that this is no longer the
case when a form contains more than a single file part stored on disk.
The previous behavior of storing each file part in a separate disk
file may be reenabled with GODEBUG=multipartfiles=distinct.
Update Reader.NextPart and Reader.NextRawPart to set a 10MiB cap
on the size of MIME headers.
Thanks to Jakob Ackermann (@das7pad) for reporting this issue.
Updates #58006
Fixes #58362
Fixes CVE-2022-41725
Change-Id: Ibd780a6c4c83ac8bcfd3cbe344f042e9940f2eab
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1714276
Reviewed-by: Julie Qiu <julieqiu@google.com>
TryBot-Result: Security TryBots <security-trybots@go-security-trybots.iam.gserviceaccount.com>
Reviewed-by: Roland Shoemaker <bracewell@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
(cherry picked from commit ed4664330edcd91b24914c9371c377c132dbce8c)
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1728949
Reviewed-by: Tatiana Bradley <tatianabradley@google.com>
Run-TryBot: Roland Shoemaker <bracewell@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/468116
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
|
|
on Windows
Do not permit Clean to convert a relative path into one starting
with a drive reference. This change causes Clean to insert a .
path element at the start of a path when the original path does not
start with a volume name, and the first path element would contain
a colon.
This may introduce a spurious but harmless . path element under
some circumstances. For example, Clean("a/../b:/../c") becomes `.\c`.
This reverts CL 401595, since the change here supersedes the one
in that CL.
Thanks to RyotaK (https://twitter.com/ryotkak) for reporting this issue.
Updates #57274
Fixes #57275
Fixes CVE-2022-41722
Change-Id: I837446285a03aa74c79d7642720e01f354c2ca17
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1675249
Reviewed-by: Roland Shoemaker <bracewell@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
Reviewed-by: Julie Qiu <julieqiu@google.com>
TryBot-Result: Security TryBots <security-trybots@go-security-trybots.iam.gserviceaccount.com>
(cherry picked from commit 780dfa043ff5192c37de0d6fd1053a66b2b9f378)
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1728206
Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Roland Shoemaker <bracewell@google.com>
Reviewed-by: Tatiana Bradley <tatianabradley@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/468115
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
TryBot-Bypass: Michael Pratt <mpratt@google.com>
|
|
If you use an external linker with --gc-sections, nothing refers
to .go.buildinfo, so the section is deleted, which in turns makes
'go version' fail on the binary. It is important for vulnerability
scanning and the like to be able to run 'go version' on any binary.
Fix this by inserting a reference to .go.buildinfo from the rodata
section, which will not be GC'ed.
Fixes #58222.
Fixes #58223.
Change-Id: I1e13e9464acaf2f5cc5e0b70476fa52b43651123
Reviewed-on: https://go-review.googlesource.com/c/go/+/464435
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-on: https://go-review.googlesource.com/c/go/+/464795
|
|
versions of external modules
In general it seems ok to assume that an open-source module that did
exist will continue to do so — after all, users of open-source modules
already do that all the time. However, we should not assume that those
modules do not publish new versions — that's really up to their
maintainers to decide.
Two existing tests did make that assumption for the module
gopkg.in/natefinch/lumberjack.v2. Let's remove those two tests.
If we need to replace them at some point, we can replace them with
hermetic test-only modules (#54503) or perhaps modules owned by the Go
project.
Updates #58445.
Fixes #58449.
Change-Id: Ica8fe587d86fc41f3d8445a4cd2b8820455ae45f
Reviewed-on: https://go-review.googlesource.com/c/go/+/466862
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
|
|
Updates #54503.
Change-Id: Ie13d028b09260d2d316c343b3ea812bb9cce4e6d
Reviewed-on: https://go-review.googlesource.com/c/go/+/424594
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
(cherry picked from commit c7f870ebc41029e07e7ffd8ff2d96b91fd83cd40)
Reviewed-on: https://go-review.googlesource.com/c/go/+/466857
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
|
|
zoneinfo_abbrs hasn't been updated since go 1.14, it's time to
regenerate it.
Fixes #58118.
Change-Id: Ic156ae607c46f1f5a9408b1fc0b56de6c14a4ed4
Reviewed-on: https://go-review.googlesource.com/c/go/+/463838
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
(cherry picked from commit 007d8f4db1f890f0d34018bb418bdc90ad4a8c35)
Reviewed-on: https://go-review.googlesource.com/c/go/+/466555
TryBot-Bypass: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Than McIntosh <thanm@google.com>
|
|
RFC 7231 permits HEAD requests to contain a body, although it does
state there are no defined semantics for payloads of HEAD requests
and that some servers may reject HEAD requests with a payload.
Accept HEAD requests with a body.
Fix a bug where a HEAD request with a chunked body would interpret
the body as the headers for the next request on the connection.
For #53960.
For #56154.
Change-Id: I83f7112fdedabd6d6291cd956151d718ee6942cd
Reviewed-on: https://go-review.googlesource.com/c/go/+/418614
Run-TryBot: Damien Neil <dneil@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-on: https://go-review.googlesource.com/c/go/+/457438
Reviewed-by: Than McIntosh <thanm@google.com>
|
|
morestack_noctxt on ppc64
In the fix for 54332 the MOVD R1, R1 instruction was added to
morestack_noctxt function to set the SPWRITE bit. However, the
instruction MOVD R1, R1 results in or r1,r1,r1 which is a special
instruction on ppc64 architecture as it changes the thread priority
and can negatively impact performance in some cases.
More details on such similar nops can be found in Power ISA v3.1
Book II on Power ISA Virtual Environment architecture in the chapter
on Program Priority Registers and Or instructions.
Replacing this by OR R0, R1 has the same affect on setting SPWRITE as
needed by the first fix but does not affect thread priority and
hence does not cause the degradation in performance
Hash65536-64 2.81GB/s ±10% 16.69GB/s ± 0% +494.44%
Fixes #57812
Change-Id: Ib912e3716c6afd277994d6c1c5b2891f82225d50
Reviewed-on: https://go-review.googlesource.com/c/go/+/461597
Reviewed-by: Benny Siegert <bsiegert@gmail.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Auto-Submit: Benny Siegert <bsiegert@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
(cherry picked from commit 1c65b69bd1dbc930c6246877f6c21c81f2a60d55)
Reviewed-on: https://go-review.googlesource.com/c/go/+/462335
Run-TryBot: Archana Ravindar <aravind5@in.ibm.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
|
|
Generating 8192 bit keys times out on builders relatively frequently. We
just need something that isn't a boringAllowCert allowed key size so we
can test that a non-boringAllowCert signed intermediate works, so just
use 512 instead since it'll be significantly faster.
Fixes #57635
Updates #56798
Change-Id: I416e0d8c3aa11ff44e9870755efa95c74d1013f1
Reviewed-on: https://go-review.googlesource.com/c/go/+/451656
Auto-Submit: Roland Shoemaker <roland@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
(cherry picked from commit 38b9ff60071fc40d197e7002db1320539e74a678)
Reviewed-on: https://go-review.googlesource.com/c/go/+/461615
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
|
|
Change-Id: I29de2897f400f576dfde497b4c51f7ee04696b36
Reviewed-on: https://go-review.googlesource.com/c/go/+/461358
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Run-TryBot: Gopher Robot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Auto-Submit: Gopher Robot <gobot@golang.org>
|
|
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 #57706.
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/+/461175
Reviewed-by: Ian Lance Taylor <iant@golang.org>
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 459178 (commit 91bc4cd118dd).
Fixes #57690.
Change-Id: Ieb38d9bc7f967e9a726429eab2ea515d5ca0847f
Reviewed-on: https://go-review.googlesource.com/c/go/+/461115
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
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 #56891
Fixes #57427
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/+/460895
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Auto-Submit: Heschi Kreinick <heschi@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
|
|
Fixes #57556
Updates #54936
Change-Id: I3fb4331c2b1b6adafbac3e76eaf66c79cd5ef56f
Reviewed-on: https://go-review.googlesource.com/c/go/+/428636
Run-TryBot: Roland Shoemaker <roland@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Auto-Submit: Roland Shoemaker <roland@golang.org>
(cherry picked from commit 56d18207823d6e1c18ca46409180c40ae800230c)
Reviewed-on: https://go-review.googlesource.com/c/go/+/460236
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Auto-Submit: Heschi Kreinick <heschi@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
|
|
LoweredAtomicCas32 on loong64,mips64x,riscv64
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 #57345
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/+/458355
Run-TryBot: David Chase <drchase@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
|
|
loong64
This is a minimum backport of CL 420983 without an API change in
debug/elf.
Original CL description:
Due to the latest binutils change [1], at least for certain 32-bit
relocs in .eh_frame section, this new type of relocation record is
emitted, leading to breakage on systems with bleeding-edge toolchain
when trying to link with object(s) with such new-style relocs.
Simply treating it the same as the existing reloc types seems enough.
Updates #54222.
Fixes #57444.
[1]: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=f09482a8747b6fd4c2d59a6a64677d3a3fe1e092
Change-Id: Idd86294a11c1d13b88acbca59e537656a57d8109
Reviewed-on: https://go-review.googlesource.com/c/go/+/458836
Reviewed-by: WANG Xuerui <git@xen0n.name>
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
|
|
For implementing interface to empty interface conversion, the compiler
generate code like:
var res *uint8
res = itab
if res != nil {
res = res.type
}
However, itab has type *uintptr, so the assignment is broken. The
problem is not shown up, until CL 450215, which call typecheck on this
broken assignment.
To fix this, just cast itab to *uint8 when doing the conversion.
Fixes #56770
Change-Id: Id42792d18e7f382578b40854d46eecd49673792c
Reviewed-on: https://go-review.googlesource.com/c/go/+/451256
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/451875
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Joedian Reid <joedian@golang.org>
|
|
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 #56837.
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/+/459178
|
|
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 #57333
Fixes #57339
Change-Id: I6680cb54dd4d3514a6887dda8906e6708c64459d
Reviewed-on: https://go-review.googlesource.com/c/go/+/457996
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Auto-Submit: Ian Lance Taylor <iant@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 #57212
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/+/456736
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 #57212
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/+/456559
Reviewed-by: Than McIntosh <thanm@google.com>
|
|
v0.0.0-20221214163817-183621ab9c4e
Update x/net to include the fix for #53960.
For #53960
For #56154
Change-Id: Ib3e0d66e4125601e20f1b2e3040f29e7ebd4b080
Reviewed-on: https://go-review.googlesource.com/c/go/+/457556
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@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 #57210
Fixes #57214
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/+/456560
Reviewed-by: Austin Clements <austin@google.com>
|
|
initialization slice
CL 440455 fixed missing walk pass for static initialization slice.
However, slicelit may produce un-typechecked node, thus we need to do
typecheck for sinit before calling walkStmtList.
Fixes #56744
Change-Id: I40730cebcd09f2be4389d71c5a90eb9a060e4ab7
Reviewed-on: https://go-review.googlesource.com/c/go/+/450215
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/451155
Reviewed-by: Joedian Reid <joedian@golang.org>
|
|
distance calculation
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 #56834
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/+/451417
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 #57055.
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/+/454955
|
|
For #56603, CL 448275 added a _ [0]T field to atomic.Pointer,
so that different kinds of atomic.Pointer are not convertible.
Unfortunately, that breaks code like:
type List struct {
Next atomic.Pointer[List]
}
which should be valid, just as using Next *List is valid.
Instead, we get:
./atomic_test.go:2533:6: invalid recursive type List
./atomic_test.go:2533:6: List refers to
./atomic_test.go:2534:13: "sync/atomic".Pointer refers to
./atomic_test.go:2533:6: List
Fix by using _[0]*T instead.
For #56638.
Fixes #57124.
Change-Id: Icc4c83c691d35961d20cb14b824223d6c779ac5e
Reviewed-on: https://go-review.googlesource.com/c/go/+/450655
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
(cherry picked from commit b14cf3d93ae5c477dd35f13f6ba41044f01a7f7d)
Reviewed-on: https://go-review.googlesource.com/c/go/+/452438
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
|
|
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 #56712.
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 3b3ab616925fb820d5168727d92f1745020f9f9d)
Reviewed-on: https://go-review.googlesource.com/c/go/+/454296
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 #57058.
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/+/454839
Reviewed-by: Michael Pratt <mpratt@google.com>
|
|
retpolines are on
Fixes #57100
Change-Id: I6ab659abbca1ae0ac8710674d39aec116fab0baa
Reviewed-on: https://go-review.googlesource.com/c/go/+/455336
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
(cherry picked from commit 1eb0465fa596a2d6e9c1a632499989544f0d7e68)
Reviewed-on: https://go-review.googlesource.com/c/go/+/455416
Reviewed-by: Michael Pratt <mpratt@google.com>
|
|
Change-Id: I5aced88de64f51c6f20ddf11dc8301bdf779a5e8
Reviewed-on: https://go-review.googlesource.com/c/go/+/455598
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Gopher Robot <gobot@golang.org>
Reviewed-by: Jenny Rakoczy <jenny@golang.org>
Auto-Submit: Gopher Robot <gobot@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
|
|
Disable cmd/internal/moddeps test, since this update includes PRIVATE
track fixes.
For #56350.
For #57009.
Fixes CVE-2022-41717.
Change-Id: I5c6ce546add81f361dcf0d5123fa4eaaf8f0a03b
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1663835
Reviewed-by: Tatiana Bradley <tatianabradley@google.com>
Reviewed-by: Julie Qiu <julieqiu@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/455363
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Jenny Rakoczy <jenny@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
|
|
http.Dir on Windows
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/+/1663834
Reviewed-by: Tatiana Bradley <tatianabradley@google.com>
Reviewed-by: Julie Qiu <julieqiu@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/455362
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Jenny Rakoczy <jenny@golang.org>
|
|
windows-amd64-2012-*
Modify skip rule for TestRaiseException to trigger on both the base
builder (windows-amd64-2012) and the oldcc legacy builder
(windows-amd64-2012-oldcc) used for 1.18/1.19 testing.
Updates #56983.
Change-Id: I132f9ddd102666b68ad04cc661fdcc2cd841051a
Reviewed-on: https://go-review.googlesource.com/c/go/+/451294
Auto-Submit: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
(cherry picked from commit f0331c524e0d8d32c3918d3515ab8413f38dbd56)
Reviewed-on: https://go-review.googlesource.com/c/go/+/454035
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Bypass: Than McIntosh <thanm@google.com>
|
|
initialized
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 #56752.
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/+/453235
|
|
FIPS-140 has been updated to allow 4096-bit RSA keys.
Allow them in certificate processing.
For #41147.
Fixes #56672.
Change-Id: I4c6bcb1b137a200dfe70cebc605ae57f49871184
Reviewed-on: https://go-review.googlesource.com/c/go/+/447655
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-on: https://go-review.googlesource.com/c/go/+/449016
|
|
TestLookupGoogleSRV
These tests fail consistently due to a DNS change causing widespread
trybot outages.
For #56707.
Fixes #56710.
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/+/449506
Reviewed-by: Ian Lance Taylor <iant@google.com>
|
