Re: [PATCH] vsock: use sock_error() to consume sk_err after connect timeout

On Wed, Jul 29, 2026 at 03:20:38PM +0200, Michal Luczaj wrote:
>On 7/29/26 15:03, Stefano Garzarella wrote:
>> On Wed, Jul 29, 2026 at 05:46:29PM +0800, Nguyen Dinh Phi [SG] wrote:
>>> On 28/7/26 16:21, Stefano Garzarella wrote:
>>>> On Fri, Jul 24, 2026 at 03:34:23PM +0800, Nguyen Dinh Phi [SG] wrote:
>>>>> On 24/7/26 05:43, Michal Luczaj wrote:
>>>>>> On 7/23/26 12:26, Nguyen Dinh Phi [SG] wrote:
>>>>>>>>>>> ...
>>>>>>>>>>> Yeah, we need to handle that part better, I think it's
>>>>>>>>>>> a leftover when
>>>>>>>>>>> we generalized AF_VSOCK to support more transport than vmci.
>>>>>>>>>
>>>>>>>>> Speaking of leftovers, I have trouble understanding where
>>>>>>>>> does vsock set
>>>>>>>>> sk_err on listener sockets anyway. If it doesn't, why vsock_accept()
>>>>>>>>> checks for it?
>>>>>>>>
>>>>>>>> I can't also see where it can be set TBH. Should we remove it ?
>>>>>>>
>>>>>>> I couldn't find it for listener side too.
>>>>>>
>>>>>> Removing sk_err handling from vsock_accept() solves the problem, right?
>>>>>>
>>>>>> thanks,
>>>>>> Michal
>>>>>
>>>>> Yes, confirmed, removing sk_err checks from vsock_accept() does
>>>>> solve the problem.
>>>>
>>>> Okay, so maybe better on going on this direction. WDYT?
>>>>
>>>> Stefano
>>>>
>>>
>>> I'm still a bit concerned about how connect() and poll() interact
>>> here, even with the sk_err checks removed from vsock_accept().
>>>
>>> For example:
>>> vsock_accept() now lets us reuse a socket whose connect() failed (call
>>> it r0) as syzbot reproducer does. After listen(), r0 becomes a
>>> listener (sk_state == TCP_LISTEN) and works correctly -- it accepts
>>> connections.
>>>
>>> But poll() on r0 still marks POLLERR, even though there is no error on
>>> that socket at that point.
>>>
>>> As I understand it, sk_err holds an error that has not yet been
>>> reported to userspace. In the blocking vsock_connect() case we have
>>> already read that error and returned it to the caller, so it is no
>>> longer pending
>>> Shouldn't sk_err be consumed/cleared when vsock_connect() returns it
>>> to userspace?
>>
>> Yeah, makes sense to me, I'll ack the v2.
>> @Michal WDYT?
>
>I'm worried this patch does not address the non-blocking connect() case.
>Could vsock_connect_timeout() set `sk->sk_err = ETIMEDOUT` after connect()
>returns?

This is a good point!

So we still need to remove `sk_err` check in vsock_accept(), or set 
`sk->sk_err = 0` in vsock_listen() to have a complete fix, right?

Thanks,
Stefano