commit d3ba94164a1c404a01369fb54ddd4f5b94d91348 [browse]
Author: Andrew Bonventre
Date: 2020-07-16 17:41:24 -04:00

[release-branch.go1.13] go1.13.14

Change-Id: Id54fd93e1839c28e40e9fcdaa5e7304dae274565
Reviewed-on: https://go-review.googlesource.com/c/go/+/243139
Run-TryBot: Andrew Bonventre <andybons@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>

commit 42e7927c5fe2da4d00786a9025bc7f8f994b0fa4 [browse]
Author: Emmanuel T Odeke
Date: 2020-07-14 18:20:47 -07:00

[release-branch.go1.13] database/sql: backport 5 Tx rollback related CLs

Manually backported the subject CLs, because of lack of
Gerrit "forge-author" permissions, but also because the prior
cherry picks didn't apply cleanly, due to a tight relation chain.

The backport comprises of:
* CL 174122
* CL 216197
* CL 223963
* CL 216240
* CL 216241

Note:
Due to the restrictions that we cannot retroactively
introduce API changes to Go1.13.13 that weren't in Go1.13, the Conn.Validator
interface (from CL 174122, CL 223963) isn't exposed, and drivers will just be
inspected, for if they have an IsValid() bool method implemented.

For a description of the content of each CL:

* CL 174122:
database/sql: process all Session Resets synchronously

Adds a new interface, driver.ConnectionValidator, to allow
drivers to signal they should not be used again,
separatly from the session resetter interface.
This is done now that the session reset is done
after the connection is put into the connection pool.

Previous behavior attempted to run Session Resets
in a background worker. This implementation had two
problems: untested performance gains for additional
complexity, and failures when the pool size
exceeded the connection reset channel buffer size.

* CL 216197:
database/sql: check conn expiry when returning to pool, not when handing it out

With the original connection reuse strategy, it was possible that
when a new connection was requested, the pool would wait for an
an existing connection to return for re-use in a full connection
pool, and then it would check if the returned connection was expired.
If the returned connection expired while awaiting re-use, it would
return an error to the location requestiong the new connection.
The existing call sites requesting a new connection was often the last
attempt at returning a connection for a query. This would then
result in a failed query.

This change ensures that we perform the expiry check right
before a connection is inserted back in to the connection pool
for while requesting a new connection. If requesting a new connection
it will no longer fail due to the connection expiring.

* CL 216240:
database/sql: prevent Tx statement from committing after rollback

It was possible for a Tx that was aborted for rollback
asynchronously to execute a query after the rollback had completed
on the database, which often would auto commit the query outside
of the transaction.

By W-locking the tx.closemu prior to issuing the rollback
connection it ensures any Tx query either fails or finishes
on the Tx, and never after the Tx has rolled back.

* CL 216241:
database/sql: on Tx rollback, retain connection if driver can reset session

Previously the Tx would drop the connection after rolling back from
a context cancel. Now if the driver can reset the session,
keep the connection.

* CL 223963
database/sql: add test for Conn.Validator interface

This addresses comments made by Russ after
https://golang.org/cl/174122 was merged. It addes a test
for the connection validator and renames the interface to just
"Validator".

Updates #31480
Updates #32530
Updates #32942
Updates #34775
Fixes #40205

Change-Id: I6d7307180b0db0bf159130d91161764cf0f18b58
Reviewed-on: https://go-review.googlesource.com/c/go/+/242522
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Daniel Theophanes <kardianos@gmail.com>

commit 6e1b89a431337a1e4584bd15f3a1af9c5c7b1bb0 [browse]
Author: Katie Hockman
Date: 2020-07-14 14:39:38 -04:00

[release-branch.go1.13] all: merge release-branch.go1.13-security into release-branch.go1.13

Change-Id: Id0cca0e1006d92960e7f665d41111483c0fcea13

commit e19af0f1447e0f99688949c68cd8c39d188f699c [browse]
Author: Marcus Weiner
Date: 2020-06-24 15:24:56 Z

[release-branch.go1.13] net/http: fix panic with If-None-Match value in http.ServeContent

Updates #39817.
Fixes #39925.

Change-Id: I79f2ad7c836a8a46569f603aca583fdd526d22dc
GitHub-Last-Rev: 5b88aada219aaa2af0c7e1969ed6fa646117d9da
GitHub-Pull-Request: golang/go#39821
Reviewed-on: https://go-review.googlesource.com/c/go/+/239699
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit ce81a8f5e4f6c33036aa0777fabc47eeeab468dc)
Reviewed-on: https://go-review.googlesource.com/c/go/+/242077
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Marcus Weiner <marcus.weiner@gmail.com>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>

commit 3c1722cf30d1edc6756022c7a12efffabcfb098a [browse]
Author: Keith Randall
Date: 2020-06-18 12:51:35 -07:00

[release-branch.go1.13] reflect: zero stack slots before writing to them with write barriers

reflect.assignTo writes to the target using write barriers. Make sure
that the memory it is writing to is zeroed, so the write barrier does
not read pointers from uninitialized memory.

Fixes #39697

Change-Id: Ia64b2cacc193bffd0c1396bbce1dfb8182d4905b
Reviewed-on: https://go-review.googlesource.com/c/go/+/238760
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
(cherry picked from commit 3dec253783e1211989102ac6abd34cddbf8ba0e6)
Reviewed-on: https://go-review.googlesource.com/c/go/+/238862
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>