Re: [PATCH net v3 5/8] vsock: treat TCP_CLOSING as once-established

On 9/24/26 15:15, netdev-bot+sashiko@kernel.org wrote:

[Severity: Low]
This isn't a bug, but the new short circuit lists only TCP_ESTABLISHED and
TCP_CLOSING as "once established", while an established socket can also be
taken straight to TCP_CLOSE by a transport event while connect() is
scheduled out:
...
The cleanup side of that case is covered by the follow-up patch in this
series, "vsock: handle socket bricking due to transport event", which adds
an early return to vsock_unconnected_reset() for sock->state ==
SS_CONNECTED or SS_DISCONNECTING, and neither of the two transport paths
above modifies sk->sk_socket->state.

Is the remaining difference in the connect() return value for the TCP_CLOSE
case the intended behaviour?

Should I use a specific return value for a socket that got bricked by
transport event?

quoted

@@ -1877,8 +1881,7 @@ static int vsock_connect(struct socket *sock, struct sockaddr_unsized *addr,
 out_wait:
 	finish_wait(sk_sleep(sk), &wait);
 out_reset:
-	if (err)
-		vsock_unconnected_reset(sk);
+	vsock_unconnected_reset(sk);

[Severity: High]
With this call now unconditional, can a VMCI detach during the handshake
turn this cleanup into a silent no-op plus a warning backtrace?

Addresses in comments to patch #3.