Go 1.27: pull in upstream changes - #175
Merged
Merged
Conversation
Pull in the fix of x/net/dns/dnsmessage panic (golang#79795). Fixes golang#79795. Change-Id: I3e9a6c7f2e934bf174bbc9e64eedc595adcfb39b Reviewed-on: https://go-review.googlesource.com/c/go/+/808660 Reviewed-by: Nicholas Husin <nsh@golang.org> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Nicholas Husin <husin@google.com>
…tack object records This fixes mips64 under qemu-user. And actually makes amd64/arm64 binaries smaller, which was the opposite of what I expected. Fixes golang#80668 Change-Id: I501f0557b12c82987a7ef60e3f91625690686379 Reviewed-on: https://go-review.googlesource.com/c/go/+/808560 Reviewed-by: Jorropo <jorropo.pgm@gmail.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Russ Cox <rsc@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Nicholas Husin <husin@google.com> (cherry picked from commit 5d29d80) Reviewed-on: https://go-review.googlesource.com/c/go/+/808800 Reviewed-by: David Chase <drchase@google.com> TryBot-Bypass: Cherry Mui <cherryyz@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com>
…ions CL 746300 refactored runtime/cgo and removed a layer of indirection to the C functions. This causes Go text section directly references the addresses of C functions. In certain build settings, this can cause dynamic relocations in the text segment, and may lead to build failures, e.g. when linking with -Bsymbolic-functions in c-shared build mode on Linux. This CL adds back the indirections, so Go text does not reference C functions directly, instead, through a Go variable. On Windows, as of CL 746300 these functions are not defined in C, so the variables remain nil. Fixes golang#80632. Change-Id: I261d23fdf6361f84d8ee10e8b850f5c78593e0b2 Reviewed-on: https://go-review.googlesource.com/c/go/+/809940 Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Quim Muntal <quimmuntal@gmail.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> (cherry picked from commit 29a8492) Reviewed-on: https://go-review.googlesource.com/c/go/+/810300
The modern way to enable/disable HTTP protocols is via
the Server.Protocols field.
Fix an unintentional change in behavior when not using
Server.Protocols:
- User sets Server.TLSNextProto to a non-nil map
which does not contain an "h2" key.
- User calls http2.ConfigureServer to add HTTP/2
support to the Server.
Historically, ConfigureServer would set the "h2" key
in TLSNextProto. After the move of HTTP/2 into std,
it no longer changes TLSNextProto. This results in
the net/http Server interpreting the missing "h2"
key in the above scenario as the user intentionally
disabling HTTP/2.
Fix this by initializing the server's HTTP/2 support
when ConfigureServer is called, which sets TLSNextProto's
"h2" key to a dummy value.
Fixes golang#80482
Change-Id: I497881423bc76deed2a59e355b59672f6a6a6964
Reviewed-on: https://go-review.googlesource.com/c/go/+/803740
Reviewed-by: Nicholas Husin <nsh@golang.org>
Reviewed-by: Nicholas Husin <husin@google.com>
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
(cherry picked from commit 857fa80)
Reviewed-on: https://go-review.googlesource.com/c/go/+/810540
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Damien Neil <dneil@google.com>
…injected calls This CL addresses two bugs related to moving goroutine stacks during injected function calls. The runtime injects calls during asynchronous preemption, when handling signals that get turned into panics (sigpanic), and for calls injected by a debugger. If a function triggers a sigpanic, and there is no way to resume execution in the function (such as through a deferred function), then that function's call frame is skipped during stack copying. The reasoning is that its locals, arguments, etc are dead. However, the call frame might contain a frame pointer. We can visit that frame pointer with the execution tracer or block/mutex profilers. If we visit that frame pointer after stack movement, it can point into the old stack. Following it will crash. This CL fixes this by adjusting the frame pointer if there is one. But it still skips the rest of the work, which is unnecessary. For arm64, there is an additonal frame pointer adjustment we're missing. Injected call frames are placed 16 bytes below the stack pointer at the point of call injection. This gap is needed both to avoid clobbering the frame pointer saved below the original function's call frame, and to have space to save the link register so it can be restored when the injected call returns. Normally when function A calls function B, the frame pointer saved below function A's frame is fixed when adjusting function B's frame. But because of the gap in the case of injection, the frame pointer saved by the original function isn't inside any call frame. We need to fix it when visiting the injected call frame. The regression test uses stackPoisonCopy so that the old stack is filled with garbage and frame pointer unwinding will reliably crash. Otherwise we'd only see a crash if something else happens to reuse the old stack space. For golang#73664 Change-Id: I600d7942521e90852c67e379679b07e96a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/730200 Reviewed-by: Mark Freeman <markfreeman@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com> (cherry picked from commit 40fd497) Reviewed-on: https://go-review.googlesource.com/c/go/+/809780 Auto-Submit: Nick Ripley <nick.ripley@datadoghq.com>
…pointer offsets This was a latent bug revealed by CL 787720 which adds a bigger than 32bits slice pointer bump in it's test suite. Updates golang#80613 Fixes golang#80740 Change-Id: I47c49f6bd5ea83821de750b0c47b17a5e038d119 Reviewed-on: https://go-review.googlesource.com/c/go/+/807120 Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Auto-Submit: Jorropo <jorropo.pgm@gmail.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Julian Zhu <jz531210@gmail.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/810040 Reviewed-by: Carlos Amedee <carlos@golang.org>
…ion of unsigned values The riscv64 lowering rules remove sign extensions after 32-bit instructions, which architecturally sign-extend their result. However regalloc restores spilled values with an extension chosen from their type: unsigned 4-byte values are restored zero-extended, losing the sign extension the rules removed. Unlike what I've assumed in 80577 where I thought lower were correct and regalloc were wrongly ignoring lower's assumptions, it's much easier to fix the issue the other way around and make lower follows the existing assumptions (shared by arm64). Only remove the extension when a spill/restore preserves it, that is when the extended value's type is 8 bytes wide, or 4 bytes wide and signed. Updates golang#80577 Fixes golang#80738 Change-Id: I3cf5cff3f9026c6501f794114e6afd537506fa63 Reviewed-on: https://go-review.googlesource.com/c/go/+/806340 LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com> Auto-Submit: Jorropo <jorropo.pgm@gmail.com> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-on: https://go-review.googlesource.com/c/go/+/810441 Reviewed-by: Carlos Amedee <carlos@golang.org> Reviewed-by: Mark Freeman <markfreeman@google.com>
…r 64bits slicemasks Updates golang#79874 Fixes golang#80741 Change-Id: I155b6571db5b3c3537c549eadfe87a14b7d5836a Reviewed-on: https://go-review.googlesource.com/c/go/+/787720 LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Carlos Amedee <carlos@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Auto-Submit: Jorropo <jorropo.pgm@gmail.com> Reviewed-by: Keith Randall <khr@google.com> (cherry picked from commit 395f4f5) Reviewed-on: https://go-review.googlesource.com/c/go/+/807223 Reviewed-by: Mark Freeman <markfreeman@google.com>
So we had an issue with some of the slices proofs. They ran in addLocalFacts which learned all values's proofs. The problem is that some proofs are only valid after executing certain values. This happens when a value adds relations in the factsTable about exclusively the value's arguments. But due to the descend / simplify separation simplify would run with all the proofs of the whole block. This CL include a huge amount of retabulation of code, all the meaningfull part is the changes to the prove function. Now we run: 1. flowLimit 2. constantFoldArguments 3. addValueFact 4. simplifyValue inside the same value loop. So thanks to toposorting, facts are learned in a valid execution order. And thanks to interleaving simplify for value v can only see v's facts. The tests from CL 807182 are included in this backport. Updates golang#80517 Fixes golang#80742 Change-Id: I36f5bce5102df55a9e5eca400dfd931c46323d71 Reviewed-on: https://go-review.googlesource.com/c/go/+/804220 Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Carlos Amedee <carlos@golang.org> Auto-Submit: Jorropo <jorropo.pgm@gmail.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> (cherry picked from commit a595f29) Reviewed-on: https://go-review.googlesource.com/c/go/+/807224 Reviewed-by: Cherry Mui <cherryyz@google.com>
…ePath
Operate on a []byte with index-based backtracking instead of calling
dst.String() and dst.WriteString() per iteration.
goos: linux
goarch: amd64
pkg: net/url
cpu: AMD EPYC 7B13
│ b/gotip │ b/fixed │
│ sec/op │ sec/op vs base │
ResolvePath/Simple 123.85n ± 1% 94.56n ± 0% -23.65% (p=0.000 n=10)
ResolvePath/Deep 1.819µ ± 1% 1.611µ ± 1% -11.41% (p=0.000 n=10)
ResolvePath/Backtrack 6.439µ ± 2% 2.280µ ± 1% -64.59% (p=0.000 n=10)
geomean 1.132µ 702.9n -37.90%
│ b/gotip │ b/fixed │
│ B/op │ B/op vs base │
ResolvePath/Simple 16.000 ± 0% 4.000 ± 0% -75.00% (p=0.000 n=10)
ResolvePath/Deep 712.0 ± 0% 624.0 ± 0% -12.36% (p=0.000 n=10)
ResolvePath/Backtrack 9064.0 ± 0% 816.0 ± 0% -91.00% (p=0.000 n=10)
geomean 469.1 126.8 -72.98%
│ b/gotip │ b/fixed │
│ allocs/op │ allocs/op vs base │
ResolvePath/Simple 2.000 ± 0% 1.000 ± 0% -50.00% (p=0.000 n=10)
ResolvePath/Deep 7.000 ± 0% 3.000 ± 0% -57.14% (p=0.000 n=10)
ResolvePath/Backtrack 107.000 ± 0% 3.000 ± 0% -97.20% (p=0.000 n=10)
geomean 11.44 2.080 -81.82%
Updates golang#80494
Fixes CVE-2026-56860
Change-Id: I0aada41a0a10e2ce77c6476a65a49abc796dff3f
Reviewed-on: https://go-review.googlesource.com/c/go/+/803681
Reviewed-by: Neal Patel <nealpatel@google.com>
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
(cherry picked from commit 594b58a)
Reviewed-on: https://go-review.googlesource.com/c/go/+/807700
Auto-Submit: Ian Alexander <jitsu@google.com>
Commit-Queue: Mark Freeman <markfreeman@google.com>
This change prevents pathological inputs from closing an unescaped `/` early, allowing for attacker-controlled data to inject arbitrary unscaped content. Additionally, CL 532595 hints at the invariant in TestEscapeText potentially getting the update this change makes. For golang#80435 Fixes CVE-2026-56858 Change-Id: I502b8960249fa9a2827b44b64d081d224ac57cbc Reviewed-on: https://go-review.googlesource.com/c/go/+/807100 Reviewed-by: Neal Patel <nealpatel@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Roland Shoemaker <roland@golang.org> (cherry picked from commit 0157ee9) Reviewed-on: https://go-review.googlesource.com/c/go/+/811040
… early The goroutine spawned per Transport.RoundTrip to write the request previously parked until the stream ended, even after the request was fully sent, just to wait for the stream-end events and run cleanupWriteRequest. For clients with many concurrent long-lived response streams (long polls, event streams), that's a parked goroutine and its stack per stream doing nothing, which adds up to a large fraction of such a client's memory use (as seen in a production load balancer). Once the request is fully sent, detach: the goroutine exits, and cleanupWriteRequest instead runs (on a short-lived goroutine) from whichever stream-ending event fires first. The only case where the goroutine stays running is if the caller uses the deprecated Request.Cancel channel, but basically nobody uses that anymore. Updates golang#80735 Change-Id: I5500c691194457195b0869c1612bf93718ca96c1 Reviewed-on: https://go-review.googlesource.com/c/go/+/810780 Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Nicholas Husin <husin@google.com> Reviewed-by: Nicholas Husin <nsh@golang.org> TryBot-Bypass: Brad Fitzpatrick <bradfitz@golang.org> (cherry picked from commit 3c0665e)
Each in-flight server response held a 4KB bufio.Writer for the lifetime of its handler, including handlers that sit idle mid-response for a very long time between writes, as when streaming long polls or server-sent events. For servers with many such concurrent streams, that's 4KB of dead weight per stream. (e.g. 40 GB of RAM at 10M streaming conns) Instead of tying the buffer to the responseWriterState for the whole response, acquire it from a pool on the first buffered write and return it to the pool whenever a Flush leaves it empty. Handlers that never flush keep the buffer until the handler completes, as before. Updates golang#80735 Change-Id: Icf7cdb5c21abb1126f6571cb00bbe2f00bf23b3c Reviewed-on: https://go-review.googlesource.com/c/go/+/811680 Reviewed-by: Nicholas Husin <husin@google.com> Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Nicholas Husin <nsh@golang.org> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> (cherry picked from commit 128a36c)
tomhjp
approved these changes
Aug 11, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
8 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Pull in more upstream Go 1.27 commits prior to its release.
Also pull in two Go 1.28 http2 memory optimizations (#174, https://github.com/tailscale/corp/issues/29053#issuecomment-5206413488)