On 9/24/26 15:15, [email protected] 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? >> @@ -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.
