delta/go-git.git/src, branch master github.com: golang/go cmd/asm: remove unsupported opcodes MOVNP and STLP for arm64 2023-05-18T01:40:37+00:00 erifan01 eric.fang@arm.com 2023-05-17T04:01:07+00:00 6ed847431709c673adbb783d3bbc3d75e4df590c ARM64 doesn't have MOVNP/MOVNPW and STLP/STLPW instructions, which are currently useless instructions as well. This CL deletes them. At the same time this CL sorts the opcodes by name, which looks cleaner. Change-Id: I25cfb636b23356ba0a50cba527a8c85b3f7e2ee4 Reviewed-on: https://go-review.googlesource.com/c/go/+/495695 Reviewed-by: Heschi Kreinick <heschi@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Run-TryBot: Eric Fang <eric.fang@arm.com> TryBot-Result: Gopher Robot <gobot@golang.org> 
ARM64 doesn't have MOVNP/MOVNPW and STLP/STLPW instructions, which are
currently useless instructions as well. This CL deletes them. At the
same time this CL sorts the opcodes by name, which looks cleaner.

Change-Id: I25cfb636b23356ba0a50cba527a8c85b3f7e2ee4
Reviewed-on: https://go-review.googlesource.com/c/go/+/495695
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Eric Fang <eric.fang@arm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
cmd/compile: enable more lenient type inference for untyped arguments 2023-05-18T00:35:53+00:00 Robert Griesemer gri@golang.org 2023-05-17T19:26:05+00:00 956d31ecd50fa11b66e4ad39a30677acb5616476 This enables the implementation for proposal #58671, which is a likely accept. By enabling it early we get a bit extra soak time for this feature. The change can be reverted trivially, if need be. For #58671. Change-Id: Id6c27515e45ff79f4f1d2fc1706f3f672ccdd1ab Reviewed-on: https://go-review.googlesource.com/c/go/+/495955 Run-TryBot: Robert Griesemer <gri@google.com> Reviewed-by: Robert Griesemer <gri@google.com> Auto-Submit: Robert Griesemer <gri@google.com> Reviewed-by: Robert Findley <rfindley@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> 
This enables the implementation for proposal #58671, which is
a likely accept. By enabling it early we get a bit extra soak
time for this feature. The change can be reverted trivially, if
need be.

For #58671.

Change-Id: Id6c27515e45ff79f4f1d2fc1706f3f672ccdd1ab
Reviewed-on: https://go-review.googlesource.com/c/go/+/495955
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
runtime/cgo: store M for C-created thread in pthread key 2023-05-17T21:53:11+00:00 Cherry Mui cherryyz@google.com 2023-05-17T16:01:15+00:00 c426c87012b5eb85b3974f1a959db6e84e55d740 This reapplies CL 485500, with a fix drafted in CL 492987 incorporated. CL 485500 is reverted due to #60004 and #60007. #60004 is fixed in CL 492743. #60007 is fixed in CL 492987 (incorporated in this CL). [Original CL 485500 description] This reapplies CL 481061, with the followup fixes in CL 482975, CL 485315, and CL 485316 incorporated. CL 481061, by doujiang24 <doujiang24@gmail.com>, speed up C to Go calls by binding the M to the C thread. See below for its description. CL 482975 is a followup fix to a C declaration in testprogcgo. CL 485315 is a followup fix for x_cgo_getstackbound on Illumos. CL 485316 is a followup cleanup for ppc64 assembly. CL 479915 passed the G to _cgo_getstackbound for direct updates to gp.stack.lo. A G can be reused on a new thread after the previous thread exited. This could trigger the C TSAN race detector because it couldn't see the synchronization in Go (lockextra) preventing the same G from being used on multiple threads at the same time. We work around this by passing the address of a stack variable to _cgo_getstackbound rather than the G. The stack is generally unique per thread, so TSAN won't see the same address from multiple threads. Even if stacks are reused across threads by pthread, C TSAN should see the synchonization in the stack allocator. A regression test is added to misc/cgo/testsanitizer. [Original CL 481061 description] This reapplies CL 392854, with the followup fixes in CL 479255, CL 479915, and CL 481057 incorporated. CL 392854, by doujiang24 <doujiang24@gmail.com>, speed up C to Go calls by binding the M to the C thread. See below for its description. CL 479255 is a followup fix for a small bug in ARM assembly code. CL 479915 is another followup fix to address C to Go calls after the C code uses some stack, but that CL is also buggy. CL 481057, by Michael Knyszek, is a followup fix for a memory leak bug of CL 479915. [Original CL 392854 description] In a C thread, it's necessary to acquire an extra M by using needm while invoking a Go function from C. But, needm and dropm are heavy costs due to the signal-related syscalls. So, we change to not dropm while returning back to C, which means binding the extra M to the C thread until it exits, to avoid needm and dropm on each C to Go call. Instead, we only dropm while the C thread exits, so the extra M won't leak. When invoking a Go function from C: Allocate a pthread variable using pthread_key_create, only once per shared object, and register a thread-exit-time destructor. And store the g0 of the current m into the thread-specified value of the pthread key, only once per C thread, so that the destructor will put the extra M back onto the extra M list while the C thread exits. When returning back to C: Skip dropm in cgocallback, when the pthread variable has been created, so that the extra M will be reused the next time invoke a Go function from C. This is purely a performance optimization. The old version, in which needm & dropm happen on each cgo call, is still correct too, and we have to keep the old version on systems with cgo but without pthreads, like Windows. This optimization is significant, and the specific value depends on the OS system and CPU, but in general, it can be considered as 10x faster, for a simple Go function call from a C thread. For the newly added BenchmarkCGoInCThread, some benchmark results: 1. it's 28x faster, from 3395 ns/op to 121 ns/op, in darwin OS & Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz 2. it's 6.5x faster, from 1495 ns/op to 230 ns/op, in Linux OS & Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz [CL 479915 description] Currently, when C calls into Go the first time, we grab an M using needm, which sets m.g0's stack bounds using the SP. We don't know how big the stack is, so we simply assume 32K. Previously, when the Go function returns to C, we drop the M, and the next time C calls into Go, we put a new stack bound on the g0 based on the current SP. After CL 392854, we don't drop the M, and the next time C calls into Go, we reuse the same g0, without recomputing the stack bounds. If the C code uses quite a bit of stack space before calling into Go, the SP may be well below the 32K stack bound we assumed, so the runtime thinks the g0 stack overflows. This CL makes needm get a more accurate stack bound from pthread. (In some platforms this may still be a guess as we don't know exactly where we are in the C stack), but it is probably better than simply assuming 32K. [CL 492987 description] On the first call into Go from a C thread, currently we set the g0 stack's high bound imprecisely based on the SP. With CL 485500, we keep the M and don't recompute the stack bounds when it calls into Go again. If the first call is made when the C thread uses some deep stack, but a subsequent call is made with a shallower stack, the SP may be above g0.stack.hi. This is usually okay as we don't check usually stack.hi. One place where we do check for stack.hi is in the signal handler, in adjustSignalStack. In particular, C TSAN delivers signals on the g0 stack (instead of the usual signal stack). If the SP is above g0.stack.hi, we don't see it is on the g0 stack, and throws. This CL makes it get an accurate stack upper bound with the pthread API (on the platforms where it is available). Also add some debug print for the "handler not on signal stack" throw. Fixes #51676. Fixes #59294. Fixes #59678. Fixes #60007. Change-Id: Ie51c8e81ade34ec81d69fd7bce1fe0039a470776 Reviewed-on: https://go-review.googlesource.com/c/go/+/495855 Run-TryBot: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com> 
This reapplies CL 485500, with a fix drafted in CL 492987 incorporated.

CL 485500 is reverted due to #60004 and #60007. #60004 is fixed in
CL 492743. #60007 is fixed in CL 492987 (incorporated in this CL).

[Original CL 485500 description]

This reapplies CL 481061, with the followup fixes in CL 482975, CL 485315, and
CL 485316 incorporated.

CL 481061, by doujiang24 <doujiang24@gmail.com>, speed up C to Go
calls by binding the M to the C thread. See below for its
description.
CL 482975 is a followup fix to a C declaration in testprogcgo.
CL 485315 is a followup fix for x_cgo_getstackbound on Illumos.
CL 485316 is a followup cleanup for ppc64 assembly.

CL 479915 passed the G to _cgo_getstackbound for direct updates to
gp.stack.lo. A G can be reused on a new thread after the previous thread
exited. This could trigger the C TSAN race detector because it couldn't
see the synchronization in Go (lockextra) preventing the same G from
being used on multiple threads at the same time.

We work around this by passing the address of a stack variable to
_cgo_getstackbound rather than the G. The stack is generally unique per
thread, so TSAN won't see the same address from multiple threads. Even
if stacks are reused across threads by pthread, C TSAN should see the
synchonization in the stack allocator.

A regression test is added to misc/cgo/testsanitizer.

[Original CL 481061 description]

This reapplies CL 392854, with the followup fixes in CL 479255,
CL 479915, and CL 481057 incorporated.

CL 392854, by doujiang24 <doujiang24@gmail.com>, speed up C to Go
calls by binding the M to the C thread. See below for its
description.
CL 479255 is a followup fix for a small bug in ARM assembly code.
CL 479915 is another followup fix to address C to Go calls after
the C code uses some stack, but that CL is also buggy.
CL 481057, by Michael Knyszek, is a followup fix for a memory leak
bug of CL 479915.

[Original CL 392854 description]

In a C thread, it's necessary to acquire an extra M by using needm while invoking a Go function from C. But, needm and dropm are heavy costs due to the signal-related syscalls.
So, we change to not dropm while returning back to C, which means binding the extra M to the C thread until it exits, to avoid needm and dropm on each C to Go call.
Instead, we only dropm while the C thread exits, so the extra M won't leak.

When invoking a Go function from C:
Allocate a pthread variable using pthread_key_create, only once per shared object, and register a thread-exit-time destructor.
And store the g0 of the current m into the thread-specified value of the pthread key,  only once per C thread, so that the destructor will put the extra M back onto the extra M list while the C thread exits.

When returning back to C:
Skip dropm in cgocallback, when the pthread variable has been created, so that the extra M will be reused the next time invoke a Go function from C.

This is purely a performance optimization. The old version, in which needm & dropm happen on each cgo call, is still correct too, and we have to keep the old version on systems with cgo but without pthreads, like Windows.

This optimization is significant, and the specific value depends on the OS system and CPU, but in general, it can be considered as 10x faster, for a simple Go function call from a C thread.

For the newly added BenchmarkCGoInCThread, some benchmark results:
1. it's 28x faster, from 3395 ns/op to 121 ns/op, in darwin OS & Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
2. it's 6.5x faster, from 1495 ns/op to 230 ns/op, in Linux OS & Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz

[CL 479915 description]

Currently, when C calls into Go the first time, we grab an M
using needm, which sets m.g0's stack bounds using the SP. We don't
know how big the stack is, so we simply assume 32K. Previously,
when the Go function returns to C, we drop the M, and the next
time C calls into Go, we put a new stack bound on the g0 based on
the current SP. After CL 392854, we don't drop the M, and the next
time C calls into Go, we reuse the same g0, without recomputing
the stack bounds. If the C code uses quite a bit of stack space
before calling into Go, the SP may be well below the 32K stack
bound we assumed, so the runtime thinks the g0 stack overflows.

This CL makes needm get a more accurate stack bound from
pthread. (In some platforms this may still be a guess as we don't
know exactly where we are in the C stack), but it is probably
better than simply assuming 32K.

[CL 492987 description]

On the first call into Go from a C thread, currently we set the g0
stack's high bound imprecisely based on the SP. With CL 485500, we
keep the M and don't recompute the stack bounds when it calls into
Go again. If the first call is made when the C thread uses some
deep stack, but a subsequent call is made with a shallower stack,
the SP may be above g0.stack.hi.

This is usually okay as we don't check usually stack.hi. One place
where we do check for stack.hi is in the signal handler, in
adjustSignalStack. In particular, C TSAN delivers signals on the
g0 stack (instead of the usual signal stack). If the SP is above
g0.stack.hi, we don't see it is on the g0 stack, and throws.

This CL makes it get an accurate stack upper bound with the
pthread API (on the platforms where it is available).

Also add some debug print for the "handler not on signal stack"
throw.

Fixes #51676.
Fixes #59294.
Fixes #59678.
Fixes #60007.

Change-Id: Ie51c8e81ade34ec81d69fd7bce1fe0039a470776
Reviewed-on: https://go-review.googlesource.com/c/go/+/495855
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
cmd/gofmt: try to write original data on rewrite failure 2023-05-17T21:44:30+00:00 Ian Lance Taylor iant@golang.org 2023-05-16T17:18:54+00:00 2693ade1fad8729b901382e418821866f64094d5 When gofmt needs to rewrite a file, it first copies it into a backup. If the rewrite fails, it used to rename the backup to the original. However, if for some reason the file is owned by some other user, and if the rewrite fails because gofmt doesn't have permission to write to the file, then renaming the backup file will change the file owner. This CL changes gofmt so that if it fails to rewrite a file, it tries to write the original contents. If writing the original content fails, it reports the problem to the user referring to the backup file, rather than trying a rename. Also create the backup file with the correct permissions, to avoid a tiny gap when some process might get write access to the file contents that it shouldn't have. (This tiny gap only applies to files that are not formatted correctly, and have read-only permission, and are in a directory with write permission.) Fixes #60225 Change-Id: Ic16dd0c85cf416d6b2345e0650d5e64413360847 Reviewed-on: https://go-review.googlesource.com/c/go/+/495316 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com> Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com> 
When gofmt needs to rewrite a file, it first copies it into a backup.
If the rewrite fails, it used to rename the backup to the original.
However, if for some reason the file is owned by some other user,
and if the rewrite fails because gofmt doesn't have permission to
write to the file, then renaming the backup file will change
the file owner. This CL changes gofmt so that if it fails to rewrite
a file, it tries to write the original contents. If writing the original
content fails, it reports the problem to the user referring to the
backup file, rather than trying a rename.

Also create the backup file with the correct permissions,
to avoid a tiny gap when some process might get write access to the
file contents that it shouldn't have. (This tiny gap only applies to
files that are not formatted correctly, and have read-only permission,
and are in a directory with write permission.)

Fixes #60225

Change-Id: Ic16dd0c85cf416d6b2345e0650d5e64413360847
Reviewed-on: https://go-review.googlesource.com/c/go/+/495316
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
cmd/compile: build compiler with PGO 2023-05-17T21:33:31+00:00 Cherry Mui cherryyz@google.com 2023-05-15T20:42:45+00:00 6111ac826ee69d6aea63faa7afebb1ef7c476b8d Reapplies CL 451292, which is reverted at CL 495475. The failure is fixed at CL 495595. Build the compiler with PGO. As go build -pgo=auto is enabled by default, we just need to store a profile in the compiler's directory. The profile is collected from building all std and cmd packages on Linux/AMD64 machine, using profile.sh. This improves the compiler speed. On Linux/AMD64, name old time/op new time/op delta Template 138ms ± 5% 136ms ± 4% -1.44% (p=0.005 n=36+39) Unicode 147ms ± 4% 140ms ± 4% -4.99% (p=0.000 n=40+39) GoTypes 780ms ± 3% 778ms ± 4% ~ (p=0.172 n=39+39) Compiler 105ms ± 5% 99ms ± 7% -5.64% (p=0.000 n=40+40) SSA 5.83s ± 6% 5.80s ± 6% ~ (p=0.556 n=40+40) Flate 89.0ms ± 5% 87.0ms ± 6% -2.18% (p=0.000 n=40+40) GoParser 172ms ± 4% 167ms ± 4% -2.72% (p=0.000 n=39+40) Reflect 333ms ± 4% 333ms ± 3% ~ (p=0.426 n=40+39) Tar 128ms ± 4% 126ms ± 4% -1.82% (p=0.000 n=39+39) XML 173ms ± 4% 170ms ± 4% -1.39% (p=0.000 n=39+40) [Geo mean] 253ms 248ms -2.13% The profile is pretty transferable. Using the same profile, we see a bigger win on Darwin/ARM64, name old time/op new time/op delta Template 71.0ms ± 2% 68.3ms ± 2% -3.90% (p=0.000 n=20+20) Unicode 71.8ms ± 2% 66.8ms ± 2% -6.90% (p=0.000 n=20+20) GoTypes 444ms ± 1% 428ms ± 1% -3.53% (p=0.000 n=19+20) Compiler 48.9ms ± 3% 45.6ms ± 3% -6.81% (p=0.000 n=20+20) SSA 3.25s ± 2% 3.09s ± 1% -5.03% (p=0.000 n=19+20) Flate 44.0ms ± 2% 42.3ms ± 2% -3.72% (p=0.000 n=19+20) GoParser 76.7ms ± 1% 73.5ms ± 1% -4.15% (p=0.000 n=18+19) Reflect 172ms ± 1% 165ms ± 1% -4.13% (p=0.000 n=20+19) Tar 63.1ms ± 1% 60.4ms ± 2% -4.24% (p=0.000 n=19+20) XML 83.2ms ± 2% 79.2ms ± 2% -4.79% (p=0.000 n=20+20) [Geo mean] 127ms 121ms -4.73% Change-Id: Ifbe35e48b3ea3b29430249b4667d2df8a2515aeb Reviewed-on: https://go-review.googlesource.com/c/go/+/495596 Run-TryBot: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com> 
Reapplies CL 451292, which is reverted at CL 495475. The failure
is fixed at CL 495595.

Build the compiler with PGO. As go build -pgo=auto is enabled by
default, we just need to store a profile in the compiler's
directory.

The profile is collected from building all std and cmd packages on
Linux/AMD64 machine, using profile.sh.

This improves the compiler speed. On Linux/AMD64,
name        old time/op       new time/op       delta
Template          138ms ± 5%        136ms ± 4%  -1.44%  (p=0.005 n=36+39)
Unicode           147ms ± 4%        140ms ± 4%  -4.99%  (p=0.000 n=40+39)
GoTypes           780ms ± 3%        778ms ± 4%    ~     (p=0.172 n=39+39)
Compiler          105ms ± 5%         99ms ± 7%  -5.64%  (p=0.000 n=40+40)
SSA               5.83s ± 6%        5.80s ± 6%    ~     (p=0.556 n=40+40)
Flate            89.0ms ± 5%       87.0ms ± 6%  -2.18%  (p=0.000 n=40+40)
GoParser          172ms ± 4%        167ms ± 4%  -2.72%  (p=0.000 n=39+40)
Reflect           333ms ± 4%        333ms ± 3%    ~     (p=0.426 n=40+39)
Tar               128ms ± 4%        126ms ± 4%  -1.82%  (p=0.000 n=39+39)
XML               173ms ± 4%        170ms ± 4%  -1.39%  (p=0.000 n=39+40)
[Geo mean]        253ms             248ms       -2.13%

The profile is pretty transferable. Using the same profile, we
see a bigger win on Darwin/ARM64,
name        old time/op       new time/op       delta
Template         71.0ms ± 2%       68.3ms ± 2%  -3.90%  (p=0.000 n=20+20)
Unicode          71.8ms ± 2%       66.8ms ± 2%  -6.90%  (p=0.000 n=20+20)
GoTypes           444ms ± 1%        428ms ± 1%  -3.53%  (p=0.000 n=19+20)
Compiler         48.9ms ± 3%       45.6ms ± 3%  -6.81%  (p=0.000 n=20+20)
SSA               3.25s ± 2%        3.09s ± 1%  -5.03%  (p=0.000 n=19+20)
Flate            44.0ms ± 2%       42.3ms ± 2%  -3.72%  (p=0.000 n=19+20)
GoParser         76.7ms ± 1%       73.5ms ± 1%  -4.15%  (p=0.000 n=18+19)
Reflect           172ms ± 1%        165ms ± 1%  -4.13%  (p=0.000 n=20+19)
Tar              63.1ms ± 1%       60.4ms ± 2%  -4.24%  (p=0.000 n=19+20)
XML              83.2ms ± 2%       79.2ms ± 2%  -4.79%  (p=0.000 n=20+20)
[Geo mean]        127ms             121ms       -4.73%

Change-Id: Ifbe35e48b3ea3b29430249b4667d2df8a2515aeb
Reviewed-on: https://go-review.googlesource.com/c/go/+/495596
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
os: if descriptor is non-blocking, retain that in Fd method 2023-05-17T21:12:04+00:00 Ian Lance Taylor iant@golang.org 2023-05-16T04:50:51+00:00 f777726ff073f8066c017649b572bd8c40940a42 For #58408 Fixes #60211 Change-Id: I30f5678b46e15121865b19d1c0f82698493fad4e Reviewed-on: https://go-review.googlesource.com/c/go/+/495079 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com> 
For #58408
Fixes #60211

Change-Id: I30f5678b46e15121865b19d1c0f82698493fad4e
Reviewed-on: https://go-review.googlesource.com/c/go/+/495079
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
crypto/x509: fix certificate validation with FQDN on Windows 2023-05-17T21:01:16+00:00 Patryk Chelmecki pat.chelmecki@gmail.com 2023-05-17T20:48:28+00:00 f0de4b4f03cdde77305b7ae14bd960130a855182 Currently certificate verification on Windows fails if the provided dns name ends with a dot (which means it is a Fully Qualified Domain Name). The certificates according to RFC 6066 (https://www.rfc-editor.org/rfc/rfc6066#section-3) do not contain that ending dot. Go uses CertVerifyCertificateChainPolicy Windows system call with CERT_CHAIN_POLICY_SSL option for verification of the certificates. That call fails if the specified domain name contains the dot at the end. Examples of other open source codebases that use the same system call and trim the trailing dot before executing it: MongoDb - https://github.com/mongodb/mongo/blob/master/src/mongo/util/net/ssl_manager_windows.cpp#L1777 Dot Net - https://github.com/dotnet/runtime/blob/v7.0.5/src/libraries/System.Net.Security/src/System/Net/Security/SslAuthenticationOptions.cs#L52 Change-Id: I5db558eb277cf00f5401ec0ffc96c935023ad100 GitHub-Last-Rev: cc69ab9be35f79a93279bd618912a3fd6aaa9f88 GitHub-Pull-Request: golang/go#59846 Reviewed-on: https://go-review.googlesource.com/c/go/+/489135 Run-TryBot: Roland Shoemaker <roland@golang.org> Reviewed-by: Roland Shoemaker <roland@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Patryk Chełmecki <patchelmecki@google.com> Auto-Submit: Roland Shoemaker <roland@golang.org> 
Currently certificate verification on Windows fails if the provided dns name ends with a dot (which means it is a Fully Qualified Domain Name). The certificates according to RFC 6066 (https://www.rfc-editor.org/rfc/rfc6066#section-3) do not contain that ending dot. Go uses CertVerifyCertificateChainPolicy Windows system call with CERT_CHAIN_POLICY_SSL option for verification of the certificates. That call fails if the specified domain name contains the dot at the end.

Examples of other open source codebases that use the same system call and trim the trailing dot before executing it:
MongoDb - https://github.com/mongodb/mongo/blob/master/src/mongo/util/net/ssl_manager_windows.cpp#L1777
Dot Net - https://github.com/dotnet/runtime/blob/v7.0.5/src/libraries/System.Net.Security/src/System/Net/Security/SslAuthenticationOptions.cs#L52

Change-Id: I5db558eb277cf00f5401ec0ffc96c935023ad100
GitHub-Last-Rev: cc69ab9be35f79a93279bd618912a3fd6aaa9f88
GitHub-Pull-Request: golang/go#59846
Reviewed-on: https://go-review.googlesource.com/c/go/+/489135
Run-TryBot: Roland Shoemaker <roland@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Patryk Chełmecki <patchelmecki@google.com>
Auto-Submit: Roland Shoemaker <roland@golang.org>
runtime: publish netpoll info after incrementing fdseq 2023-05-17T20:12:00+00:00 Ian Lance Taylor iant@golang.org 2023-05-16T23:03:38+00:00 a1674f3ee30bf46d22fcac115529ce830f8c9ac9 I think there is a theoretical possibility of a mistake before this CL. pollCache.free would increment fdseq, but would not update atomicInfo. The epoll code could compare to fdseq before the increment, but suspend before calling setEventErr. The pollCache could get reallocated, and pollOpen could clear eventErr. Then the setEventErr could continue and set it again. Then pollOpen could call publishInfo. Avoid this rather remote possibility by calling publishInfo after incrementing fdseq. That ensures that delayed setEventErr will not modify the eventErr flag. Fixes #60133 Change-Id: I69e336535312544690821c9fd53f3023ff15b80c Reviewed-on: https://go-review.googlesource.com/c/go/+/495297 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com> Reviewed-by: Bryan Mills <bcmills@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com> 
I think there is a theoretical possibility of a mistake before this CL.
pollCache.free would increment fdseq, but would not update atomicInfo.
The epoll code could compare to fdseq before the increment, but suspend
before calling setEventErr. The pollCache could get reallocated,
and pollOpen could clear eventErr. Then the setEventErr could continue
and set it again. Then pollOpen could call publishInfo.

Avoid this rather remote possibility by calling publishInfo after
incrementing fdseq. That ensures that delayed setEventErr will not
modify the eventErr flag.

Fixes #60133

Change-Id: I69e336535312544690821c9fd53f3023ff15b80c
Reviewed-on: https://go-review.googlesource.com/c/go/+/495297
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
cmd/link, internal/abi: minor follow-up cleanups 2023-05-17T18:24:13+00:00 David Chase drchase@google.com 2023-05-17T14:37:18+00:00 8c822ac7e8e136f079359be1772c1ba3f06399e6 these address comments on CLs in the large refactoring stack recently submitted. Change-Id: Ic9023c32aafe4dda953b42c9a36834d3ab3432eb Reviewed-on: https://go-review.googlesource.com/c/go/+/495835 Reviewed-by: Than McIntosh <thanm@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: David Chase <drchase@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> 
these address comments on CLs in the large refactoring stack
recently submitted.

Change-Id: Ic9023c32aafe4dda953b42c9a36834d3ab3432eb
Reviewed-on: https://go-review.googlesource.com/c/go/+/495835
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
cmd/dist: add -json flag 2023-05-17T18:18:37+00:00 Austin Clements austin@google.com 2023-05-11T20:20:36+00:00 93477f0770a1a0514916e458d077d767787d72f5 This enables JSON output for all tests run by dist. Most the complexity here is that, in order to disambiguate JSON records from different package variants, we have to rewrite the JSON stream on the fly to include variant information. We do this by rewriting the Package field to be pkg:variant so existing CI systems will naturally pick up the disambiguated test name. Fixes #37486. Change-Id: I0094e5e27b3a02ffc108534b8258c699ed8c3b87 Reviewed-on: https://go-review.googlesource.com/c/go/+/494958 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> 
This enables JSON output for all tests run by dist.

Most the complexity here is that, in order to disambiguate JSON
records from different package variants, we have to rewrite the JSON
stream on the fly to include variant information. We do this by
rewriting the Package field to be pkg:variant so existing CI systems
will naturally pick up the disambiguated test name.

Fixes #37486.

Change-Id: I0094e5e27b3a02ffc108534b8258c699ed8c3b87
Reviewed-on: https://go-review.googlesource.com/c/go/+/494958
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>