Re: [PATCH net v2] vsock/bpf: release sock lock while waiting for data in recvmsg

[jrmmhm . kernel]

On Mon, 05 Oct 2026 21:26:03 +0000, netdev-bot+sashiko@xxxxxxxxxx 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