On Fri, Oct 30, 2026 at 03:25:26PM +0100, Stefano Garzarella wrote: > Ditto.
Same as for 1/2, I'll rewrite it. > >+ if (unlikely(flags & MSG_ERRQUEUE)) > >+ return __vsock_recvmsg(sk, msg, len, flags); > > If the psock ingress queue is not empty, wouldn't recvmsg(MSG_ERRQUEUE) > (e.g. a MSG_ZEROCOPY user reading completions) also consume stream bytes > through sk_msg_recvmsg(), since it only looks at MSG_PEEK? If so, maybe > worth mentioning in the commit message. Yes, when the read passes a buffer. I reproduced it: without this patch a 1-byte MSG_ERRQUEUE read with stream data in the psock ingress queue returns that byte. A zero-length read, as MSG_ZEROCOPY users do, takes none, but never reaches the error queue either: it gets -EAGAIN instead of the completion. Routing MSG_ERRQUEUE first fixes both; I'll mention it in the message. > >+ if (flags & MSG_OOB) > >+ return -EOPNOTSUPP; > >+ > >+ if (!len) > >+ return 0; > > Is the order of the checks important? We should mention it in the commit > description (if it's important or not and why). Yes. MSG_ERRQUEUE must come first, or a zero-length error-queue read returns 0. MSG_OOB goes before len == 0 so that recv(fd, buf, 0, MSG_OOB) returns -EOPNOTSUPP as in the native path on a connected socket. I'll say so in the message. Thanks, Jerome
