Re: [PATCH net v2 5/5] vsock: Handle sudden TCP_CLOSE during connect

[sashiko-bot@kernel.org]

> Virtio/PM events are serviced by virtio_vsock_reset_sock(), which resets
> each connected socket. The reset is done under vsock_table_lock but without
> taking lock_sock(), so from the point of view of vsock_connect() -
> locklessly. The same pattern exists in VMCI's
> vmci_transport_handle_detach() and vhost's vhost_vsock_reset_orphans().
> 
> The complexity of connect() comes from the fact that:
> 1. the virtio transport can be reassigned, so the old transport must be
>    safely released;
> 2. a failed connect can be followed by a retry, so the socket must be
>    reverted to a sensible state.
> Both cases apply only as long as the socket has not yet established a
> connection.
> 
> While connect() waits for TCP_SYN_SENT -> TCP_ESTABLISHED, other
> transitions can also occur:
> 
>   TCP_SYN_SENT -> TCP_CLOSE on connection failure, timeout or signal
>   TCP_SYN_SENT -> TCP_ESTABLISHED -> TCP_CLOSING on VIRTIO_VSOCK_OP_RST
>   TCP_SYN_SENT -> TCP_ESTABLISHED -> [TCP_CLOSING ->] TCP_CLOSE on event
> 
> This further complicates connect(). Rather than making every event handler
> drop the socket from connected_table or adapting connect() to handle more
> transitions (while missing proper locking), use vsk->peer_shutdown as a
> poison flag. Whatever state an event leaves the socket in, the flag bricks
> it and prevents suspicious transport reassignments or TCP_SYN_SENT
> retransmissions.
> 
> Fixes: d021c344051a ("VSOCK: Introduce VM Sockets")
> Signed-off-by: Michal Luczaj <mhal@rbox.co>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260915-vsock-connect-reset-closing-v2-0-a1d9abb472f7@rbox.co?part=5