On Thu, Apr 2, 2026 at 5:03 AM Stefano Garzarella <[email protected]> wrote:
> >Scheduling a timeout for a non-blocking accept with an empty backlog
> >meant AF_VSOCK sockets used by epoll network servers incurred hundreds
> >of microseconds of additional latency per accept loop compared to
> >AF_INET or AF_UNIX sockets.
>
> Not related to this patch, but should we do something similar (in
> another patch) also in vsock_connect() or doesn't matter since usually
> it's always blocking?
Looking at vsock_connect it's not immediately obvious to me whether it
is affected
in the same way. I'll capture some ftraces and follow up after
updating this patch.
> >diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
> >index 2f7d94d682..483889b6d8 100644
> >--- a/net/vmw_vsock/af_vsock.c
> >+++ b/net/vmw_vsock/af_vsock.c
> >@@ -1850,11 +1850,11 @@ static int vsock_accept(struct socket *sock, struct
> >socket *newsock,
> > * created upon connection establishment.
> > */
> > timeout = sock_rcvtimeo(listener, arg->flags & O_NONBLOCK);
> >- prepare_to_wait(sk_sleep(listener), &wait, TASK_INTERRUPTIBLE);
> >
> > while ((connected = vsock_dequeue_accept(listener)) == NULL &&
> >- listener->sk_err == 0) {
> >+ listener->sk_err == 0 && timeout != 0) {
> > release_sock(listener);
> >+ prepare_to_wait(sk_sleep(listener), &wait,
> >TASK_INTERRUPTIBLE);
>
> Is it okay to move prepare_to_wait() after `release_sock(listener)`?
>
> I'm worried if we can miss any wakeup. BTW if this change is okay, we
> should document that at least in the commit description.
I'm not sure. I'll swap them around so they are the same order as before.
> From checkpatch:
> CHECK: Comparison to NULL could be written "!connected"
> #58: FILE: net/vmw_vsock/af_vsock.c:1870:
> + } else if (timeout == 0 && connected == NULL) {
>
> >+ err = -EAGAIN;
> >+ goto out;
> >+ }
>
> What about simplifying this with (not a strong opinion):
>
> } else if (connected == NULL) {
> err = -EAGAIN;
> }
That definitely seems cleaner.
> Also
> https://patchwork.kernel.org/project/netdevbpf/patch/[email protected]/
> suggests to specify a tree (net-next I think for this change) and be
> sure to CC other maintainers (scripts/get_maintainer.pl can help).
Sorry about that, first kernel patch submission. Will do so when I
send the updated patch.
Laurence
