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

[Michal Luczaj <mhal@rbox.co>]

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?

>> @@ -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.