> 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 <[email protected]>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review ยท
https://sashiko.dev/#/patchset/[email protected]?part=5
