On Mon, 05 Oct 2026 21:26:03 +0000, [email protected] wrote: > [Severity: Medium] > Can this loop sleep forever on a connection that has already been reset? [...] > Should the loop also check sk->sk_state and SOCK_DONE, so that case still > works after the error has been read?
Yes. I reproduced it by unbinding the guest's virtio-vsock device under an established sockmap'd connection: after getsockopt(SO_ERROR), recv() waited for the whole SO_RCVTIMEO and returned -EAGAIN, while a socket outside the sockmap returned -ENOTCONN at once. v3 ends the wait once the socket is no longer TCP_ESTABLISHED, with 0 if SOCK_DONE is set and -ENOTCONN otherwise, as __vsock_connectible_recvmsg() does. > [Severity: Low] > Should MSG_OOB be rejected here as well, next to MSG_ERRQUEUE? [...] > Rejecting MSG_OOB next to the new MSG_ERRQUEUE check would fix both > cases. Agreed, both cases reproduce. v3 rejects MSG_OOB with -EOPNOTSUPP before the len == 0 check, as unix_bpf_recvmsg() does, so it neither returns 0 nor consumes ordinary bytes. > [Severity: High] > This isn't a bug introduced by this patch, but the patch rewrites the code > around it. Can a blocking recv() hang here while data is waiting in > psock->ingress_msg? [...] > Should this fallback also take psock->ingress_skb into account? I agree with the analysis (from reading the code; I have not reproduced it): vsock_has_data() counts psock->ingress_skb while sk_psock_queue_empty() looks only at ingress_msg, so data that is still on ingress_skb sends the reader to the native path, which never looks at the psock queues. It predates this series. The loop adds one more way into the same window, but the fix belongs in the fallback condition, so I'll send it as a separate patch. v3 also splits the change into two patches, following Michal's remark on v2; it will go out as a new thread. pw-bot: cr
