On 3/28/25 3:15 PM, Stefano Garzarella wrote: > From: Stefano Garzarella <[email protected]> > > When a peer attempts to establish a connection, vsock_connect() contains > a loop that waits for the state to be TCP_ESTABLISHED. However, the > other peer can be fast enough to accept the connection and close it > immediately, thus moving the state to TCP_CLOSING. > > When this happens, the peer in the vsock_connect() is properly woken up, > but since the state is not TCP_ESTABLISHED, it goes back to sleep > until the timeout expires, returning -ETIMEDOUT. > > If the socket state is TCP_CLOSING, waiting for the timeout is pointless. > vsock_connect() can return immediately without errors or delay since the > connection actually happened. The socket will be in a closing state, > but this is not an issue, and subsequent calls will fail as expected. > > We discovered this issue while developing a test that accepts and > immediately closes connections to stress the transport switch between > two connect() calls, where the first one was interrupted by a signal > (see Closes link). > > Reported-by: Luigi Leonardi <[email protected]> > Closes: > https://lore.kernel.org/virtualization/bq6hxrolno2vmtqwcvb5bljfpb7mvwb3kohrvaed6auz5vxrfv@ijmd2f3grobn/ > Fixes: d021c344051a ("VSOCK: Introduce VM Sockets") > Signed-off-by: Stefano Garzarella <[email protected]>
Acked-by: Paolo Abeni <[email protected]>
