aboutsummaryrefslogtreecommitdiff
path: root/src/runtime
diff options
context:
space:
mode:
authorDamien Neil <dneil@google.com>2026-02-05 15:56:13 -0800
committerGopher Robot <gobot@golang.org>2026-02-05 17:05:55 -0800
commitd4febb45179fa99ee1d5783bcb693ed7ba14115c (patch)
tree35ae07eb6d4a57147a4b089cbd7907d1871f41af /src/runtime
parente2a34c7e9b04564ddad50bd7ec7b52fabde74192 (diff)
downloadgo-d4febb45179fa99ee1d5783bcb693ed7ba14115c.tar.xz
crypto/tls: avoid data race when canceling a QUICConn's Context
Methods on QUICConn are synchronous: The connection state is expected to change only in reaction to a user calling a QUICConn method, and the state change should finish completely before the method returns. The connection context provided to QUICConn.Start violates this model, because canceling the context causes an asynchronous state change. Prior to CL 719040, this caused no problems because canceling the context did not cause any user-visible state changes. In particular, canceling the context did not cause any new events to be immediately returned by QUICConn.NextEvent. CL 719040 introduced a new error event. Now, canceling a QUICConn's context causes a new connection event to be generated. Receiving this event causes a data race visible to the race detector, but the core problem is not the data race itself: It's that an asynchronous event (canceling the connection context) causes an change to the connection events. Fix this race by reworking the handling of QUICConn context cancellation a bit. We no longer react to cancellation while control of the connection lies with the user. We only process cancellation as part of a user call, such as QUICConn.Close or QUICConn.HandleData. Fixes #77274 Change-Id: If2e0f73618c4852114e0931b6bd0cb0b6a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/742561 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Damien Neil <dneil@google.com> Reviewed-by: Roland Shoemaker <roland@golang.org>
Diffstat (limited to 'src/runtime')
0 files changed, 0 insertions, 0 deletions