[PATCH net-next v2 0/2] vsock: fold acceptq accounting into core helpers

[PATCH net-next v2 0/2] vsock: fold acceptq accounting into core helpers

[Raf Dickson]

These two patches follow up on commit c05fa14db43e
("vsock/vmci: fix sk_ack_backlog leak on failed handshake")
by folding sk_acceptq_added() and sk_acceptq_removed() into
vsock_enqueue_accept() and vsock_remove_pending() respectively,
as suggested by Paolo Abeni and Stefano Garzarella.

Changes since v1:
  - Keep sk_acceptq_added() explicit in vmci, where it pairs with
    vsock_add_pending() rather than vsock_enqueue_accept() (Bobby Eshleman)

Link: https://lore.kernel.org/netdev/20260610091121.213324-1-rafdog35@gmail.com/


Raf Dickson (2):
  vsock: fold sk_acceptq_added() into vsock_enqueue_accept()
  vsock: fold sk_acceptq_removed() into vsock_remove_pending()

 net/vmw_vsock/af_vsock.c                | 4 ++--
 net/vmw_vsock/hyperv_transport.c        | 1 -
 net/vmw_vsock/virtio_transport_common.c | 1 -
 net/vmw_vsock/vmci_transport.c          | 5 +----
 4 files changed, 3 insertions(+), 8 deletions(-)

-- 
2.54.0

[PATCH net-next v2 1/2] vsock: fold sk_acceptq_added() into vsock_enqueue_accept()

[Raf Dickson]

virtio and hyperv call sk_acceptq_added() immediately before
vsock_enqueue_accept(). Move the call into vsock_enqueue_accept()
itself so callers cannot forget it and the accounting is consistent.

vmci is left unchanged as sk_acceptq_added() there pairs with
vsock_add_pending(), not vsock_enqueue_accept(), since connections
can be cleaned up by the pending work timer before ever reaching
vsock_enqueue_accept().

Suggested-by: Paolo Abeni <pabeni@redhat.com>
Suggested-by: Stefano Garzarella <sgarzare@redhat.com>

Signed-off-by: Raf Dickson <rafdog35@gmail.com>
---
 net/vmw_vsock/af_vsock.c                | 1 +
 net/vmw_vsock/hyperv_transport.c        | 1 -
 net/vmw_vsock/virtio_transport_common.c | 1 -
 3 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index 2ce1063d4a..73e6416ee9 100644
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -507,6 +507,7 @@ void vsock_enqueue_accept(struct sock *listener, struct sock *connected)
 	sock_hold(connected);
 	sock_hold(listener);
 	list_add_tail(&vconnected->accept_queue, &vlistener->accept_queue);
+	sk_acceptq_added(listener);
 }
 EXPORT_SYMBOL_GPL(vsock_enqueue_accept);
 
diff --git a/net/vmw_vsock/hyperv_transport.c b/net/vmw_vsock/hyperv_transport.c
index b3394946b2..0de8148877 100644
--- a/net/vmw_vsock/hyperv_transport.c
+++ b/net/vmw_vsock/hyperv_transport.c
@@ -410,7 +410,6 @@ static void hvs_open_connection(struct vmbus_channel *chan)
 
 	if (conn_from_host) {
 		new->sk_state = TCP_ESTABLISHED;
-		sk_acceptq_added(sk);
 
 		hvs_new->vm_srv_id = *if_type;
 		hvs_new->host_srv_id = *if_instance;
diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
index b10666937c..4a39d48db9 100644
--- a/net/vmw_vsock/virtio_transport_common.c
+++ b/net/vmw_vsock/virtio_transport_common.c
@@ -1582,7 +1582,6 @@ virtio_transport_recv_listen(struct sock *sk, struct sk_buff *skb,
 		return ret;
 	}
 
-	sk_acceptq_added(sk);
 	if (virtio_transport_space_update(child, skb))
 		child->sk_write_space(child);
 
-- 
2.54.0

[PATCH net-next v2 2/2] vsock: fold sk_acceptq_removed() into vsock_remove_pending()

[Raf Dickson]

Callers of vsock_remove_pending() must also call sk_acceptq_removed()
to keep sk_ack_backlog consistent. Move the call into
vsock_remove_pending() itself to make it automatic and prevent future
callers from forgetting it.

Suggested-by: Stefano Garzarella <sgarzare@redhat.com>
Signed-off-by: Raf Dickson <rafdog35@gmail.com>
---
 net/vmw_vsock/af_vsock.c       | 3 +--
 net/vmw_vsock/vmci_transport.c | 5 +----
 2 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index 73e6416ee9..b9772a0205 100644
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -493,6 +493,7 @@ void vsock_remove_pending(struct sock *listener, struct sock *pending)
 	list_del_init(&vpending->pending_links);
 	sock_put(listener);
 	sock_put(pending);
+	sk_acceptq_removed(listener);
 }
 EXPORT_SYMBOL_GPL(vsock_remove_pending);
 
@@ -761,8 +762,6 @@ static void vsock_pending_work(struct work_struct *work)
 
 	if (vsock_is_pending(sk)) {
 		vsock_remove_pending(listener, sk);
-
-		sk_acceptq_removed(listener);
 	} else if (!vsk->rejected) {
 		/* We are not on the pending list and accept() did not reject
 		 * us, so we must have been accepted by our user process.  We
diff --git a/net/vmw_vsock/vmci_transport.c b/net/vmw_vsock/vmci_transport.c
index 91516488a7..a417403c8d 100644
--- a/net/vmw_vsock/vmci_transport.c
+++ b/net/vmw_vsock/vmci_transport.c
@@ -980,11 +980,8 @@ static int vmci_transport_recv_listen(struct sock *sk,
 			err = -EINVAL;
 		}
 
-		if (err < 0) {
+		if (err < 0)
 			vsock_remove_pending(sk, pending);
-			sk_acceptq_removed(sk);
-		}
-
 		release_sock(pending);
 		vmci_transport_release_pending(pending);
 
-- 
2.54.0

Re: [PATCH net-next v2 1/2] vsock: fold sk_acceptq_added() into vsock_enqueue_accept()

[Stefano Garzarella]

On Thu, Jun 11, 2026 at 02:13:16AM +0000, Raf Dickson wrote:
>virtio and hyperv call sk_acceptq_added() immediately before
>vsock_enqueue_accept(). Move the call into vsock_enqueue_accept()
>itself so callers cannot forget it and the accounting is consistent.
>
>vmci is left unchanged as sk_acceptq_added() there pairs with

I'm confused, vmci is also calling vsock_enqueue_accept(), are we 
calling sk_acceptq_added() twice?

Aaaah, vmci is calling vsock_enqueue_accept() after 
vsock_remove_pending(), so IIUC with the next patch we fix this, so 
should we reverse the order of the patches?

Also, should we avoid this?
Maybe adding a new function that moves a socket from the pending queue 
to the accept queue avoiding also sock_put/sock_hold dance and 
sk_acceptq_removed()/sk_acceptq_added().

I mean something like this (untested):

void vsock_pending_to_accept(struct sock *listener, struct sock *pending)
{
	struct vsock_sock *vpending = vsock_sk(pending);
	struct vsock_sock *vlistener = vsock_sk(listener);

	list_del_init(&vpending->pending_links);
	list_add_tail(&vpending->accept_queue, &vlistener->accept_queue);
}

To be called in vmci_transport_recv_connecting_server().

WDYT?

>vsock_add_pending(), not vsock_enqueue_accept(), since connections

So can we move sk_acceptq_added() also in vsock_add_pending()?
(with another patch I guess)

Thanks,
Stefano

>can be cleaned up by the pending work timer before ever reaching
>vsock_enqueue_accept().
>
>Suggested-by: Paolo Abeni <pabeni@redhat.com>
>Suggested-by: Stefano Garzarella <sgarzare@redhat.com>
>
>Signed-off-by: Raf Dickson <rafdog35@gmail.com>
>---
> net/vmw_vsock/af_vsock.c                | 1 +
> net/vmw_vsock/hyperv_transport.c        | 1 -
> net/vmw_vsock/virtio_transport_common.c | 1 -
> 3 files changed, 1 insertion(+), 2 deletions(-)
>
>diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
>index 2ce1063d4a..73e6416ee9 100644
>--- a/net/vmw_vsock/af_vsock.c
>+++ b/net/vmw_vsock/af_vsock.c
>@@ -507,6 +507,7 @@ void vsock_enqueue_accept(struct sock *listener, struct sock *connected)
> 	sock_hold(connected);
> 	sock_hold(listener);
> 	list_add_tail(&vconnected->accept_queue, &vlistener->accept_queue);
>+	sk_acceptq_added(listener);
> }
> EXPORT_SYMBOL_GPL(vsock_enqueue_accept);
>
>diff --git a/net/vmw_vsock/hyperv_transport.c b/net/vmw_vsock/hyperv_transport.c
>index b3394946b2..0de8148877 100644
>--- a/net/vmw_vsock/hyperv_transport.c
>+++ b/net/vmw_vsock/hyperv_transport.c
>@@ -410,7 +410,6 @@ static void hvs_open_connection(struct vmbus_channel *chan)
>
> 	if (conn_from_host) {
> 		new->sk_state = TCP_ESTABLISHED;
>-		sk_acceptq_added(sk);
>
> 		hvs_new->vm_srv_id = *if_type;
> 		hvs_new->host_srv_id = *if_instance;
>diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
>index b10666937c..4a39d48db9 100644
>--- a/net/vmw_vsock/virtio_transport_common.c
>+++ b/net/vmw_vsock/virtio_transport_common.c
>@@ -1582,7 +1582,6 @@ virtio_transport_recv_listen(struct sock *sk, struct sk_buff *skb,
> 		return ret;
> 	}
>
>-	sk_acceptq_added(sk);
> 	if (virtio_transport_space_update(child, skb))
> 		child->sk_write_space(child);
>
>-- 
>2.54.0
>

Re: [PATCH net-next v2 2/2] vsock: fold sk_acceptq_removed() into vsock_remove_pending()

[Stefano Garzarella]

On Thu, Jun 11, 2026 at 02:13:17AM +0000, Raf Dickson wrote:
>Callers of vsock_remove_pending() must also call sk_acceptq_removed()
>to keep sk_ack_backlog consistent. Move the call into
>vsock_remove_pending() itself to make it automatic and prevent future
>callers from forgetting it.
>
>Suggested-by: Stefano Garzarella <sgarzare@redhat.com>
>Signed-off-by: Raf Dickson <rafdog35@gmail.com>
>---
> net/vmw_vsock/af_vsock.c       | 3 +--
> net/vmw_vsock/vmci_transport.c | 5 +----
> 2 files changed, 2 insertions(+), 6 deletions(-)
>
>diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
>index 73e6416ee9..b9772a0205 100644
>--- a/net/vmw_vsock/af_vsock.c
>+++ b/net/vmw_vsock/af_vsock.c
>@@ -493,6 +493,7 @@ void vsock_remove_pending(struct sock *listener, struct sock *pending)
> 	list_del_init(&vpending->pending_links);
> 	sock_put(listener);
> 	sock_put(pending);
>+	sk_acceptq_removed(listener);
> }

I'm unsure about the ordering of patches. Now that I'm looking at this, 
it's clear that 2 patches are really related and can't be split without 
breaking the bisectability.

Maybe we can keep these patches separated (which I like) if we introduce 
the vsock_pending_to_accept() I suggested with an initial patch of the 
series (feel free to chose another name, I'm not great at naming xD).

Thanks,
Stefano

> EXPORT_SYMBOL_GPL(vsock_remove_pending);
>
>@@ -761,8 +762,6 @@ static void vsock_pending_work(struct work_struct *work)
>
> 	if (vsock_is_pending(sk)) {
> 		vsock_remove_pending(listener, sk);
>-
>-		sk_acceptq_removed(listener);
> 	} else if (!vsk->rejected) {
> 		/* We are not on the pending list and accept() did not reject
> 		 * us, so we must have been accepted by our user process.  We
>diff --git a/net/vmw_vsock/vmci_transport.c b/net/vmw_vsock/vmci_transport.c
>index 91516488a7..a417403c8d 100644
>--- a/net/vmw_vsock/vmci_transport.c
>+++ b/net/vmw_vsock/vmci_transport.c
>@@ -980,11 +980,8 @@ static int vmci_transport_recv_listen(struct sock *sk,
> 			err = -EINVAL;
> 		}
>
>-		if (err < 0) {
>+		if (err < 0)
> 			vsock_remove_pending(sk, pending);
>-			sk_acceptq_removed(sk);
>-		}
>-
> 		release_sock(pending);
> 		vmci_transport_release_pending(pending);
>
>-- 
>2.54.0
>

Re: [PATCH net-next v2 1/2] vsock: fold sk_acceptq_added() into vsock_enqueue_accept()

[Raf Dickson]

On Thu, Jun 11, 2026 at 10:27:42AM +0200, Stefano Garzarella wrote:
> Maybe adding a new function that moves a socket from the pending queue
> to the accept queue avoiding also sock_put/sock_hold dance and
> sk_acceptq_removed()/sk_acceptq_added().
>
> To be called in vmci_transport_recv_connecting_server().
>
> So can we move sk_acceptq_added() also in vsock_add_pending()?

I like the vsock_pending_to_accept() approach, it makes the vmci
path clean without the double-accounting issue. Will send a v3 series
with that as patch 1, followed by folding sk_acceptq_added() into
vsock_add_pending() and sk_acceptq_removed() into vsock_remove_pending()
as separate patches.

Any preference on the name xd? vsock_pending_to_accept() works for me.

Raf

Re: [PATCH net-next v2 2/2] vsock: fold sk_acceptq_removed() into vsock_remove_pending()

[Raf Dickson]

On Thu, Jun 11, 2026 at 10:35:23AM +0200, Stefano Garzarella wrote:
> Maybe we can keep these patches separated (which I like) if we
> introduce the vsock_pending_to_accept() I suggested with an initial
> patch of the series.

Agreed. Will restructure as a v3 series:
  1/3: introduce vsock_pending_to_accept() for vmci
  2/3: fold sk_acceptq_added() into vsock_add_pending()
  3/3: fold sk_acceptq_removed() into vsock_remove_pending()

Raf

Re: [PATCH net-next v2 1/2] vsock: fold sk_acceptq_added() into vsock_enqueue_accept()

[Stefano Garzarella]

On Thu, Jun 11, 2026 at 08:55:37AM +0000, Raf Dickson wrote:
>On Thu, Jun 11, 2026 at 10:27:42AM +0200, Stefano Garzarella wrote:
>> Maybe adding a new function that moves a socket from the pending queue
>> to the accept queue avoiding also sock_put/sock_hold dance and
>> sk_acceptq_removed()/sk_acceptq_added().
>>
>> To be called in vmci_transport_recv_connecting_server().
>>
>> So can we move sk_acceptq_added() also in vsock_add_pending()?
>
>I like the vsock_pending_to_accept() approach, it makes the vmci
>path clean without the double-accounting issue. Will send a v3 series
>with that as patch 1, followed by folding sk_acceptq_added() into
>vsock_add_pending() and sk_acceptq_removed() into vsock_remove_pending()
>as separate patches.

Okay, but VMCI still need to call vsock_add_pending() and 
sk_acceptq_added() in vmci_transport_recv_listen(), no?

>
>Any preference on the name xd? vsock_pending_to_accept() works for me.

Also for me :-)

Stefano

Re: [PATCH net-next v2 2/2] vsock: fold sk_acceptq_removed() into vsock_remove_pending()

[Stefano Garzarella]

On Thu, Jun 11, 2026 at 08:56:03AM +0000, Raf Dickson wrote:
>On Thu, Jun 11, 2026 at 10:35:23AM +0200, Stefano Garzarella wrote:
>> Maybe we can keep these patches separated (which I like) if we
>> introduce the vsock_pending_to_accept() I suggested with an initial
>> patch of the series.
>
>Agreed. Will restructure as a v3 series:
>  1/3: introduce vsock_pending_to_accept() for vmci
>  2/3: fold sk_acceptq_added() into vsock_add_pending()
>  3/3: fold sk_acceptq_removed() into vsock_remove_pending()

IMO would be nice to have also a patch to fold sk_acceptq_added() in 
vsock_add_pending().

The rest LGTM.

Stefano

Re: [PATCH net-next v2 1/2] vsock: fold sk_acceptq_added() into vsock_enqueue_accept()

[Raf Dickson]

On Thu, Jun 11, 2026 at 09:42:12AM +0200, Stefano Garzarella wrote:
> Okay, but VMCI still need to call vsock_add_pending() and
> sk_acceptq_added() in vmci_transport_recv_listen(), no?

Yes correct, vsock_add_pending() and sk_acceptq_added() stay in
recv_listen(). vsock_pending_to_accept() only replaces the
vsock_remove_pending() + vsock_enqueue_accept() calls in
recv_connecting_server() once the handshake completes.

So the v3 series will be 4 patches:
  1/4: introduce vsock_pending_to_accept()
  2/4: fold sk_acceptq_added() into vsock_add_pending()
  3/4: fold sk_acceptq_added() into vsock_enqueue_accept() (virtio/hyperv)
  4/4: fold sk_acceptq_removed() into vsock_remove_pending()

Raf

Re: [PATCH net-next v2 1/2] vsock: fold sk_acceptq_added() into vsock_enqueue_accept()

[Stefano Garzarella]

On Thu, Jun 11, 2026 at 09:55:09AM +0000, Raf Dickson wrote:
>On Thu, Jun 11, 2026 at 09:42:12AM +0200, Stefano Garzarella wrote:
>> Okay, but VMCI still need to call vsock_add_pending() and
>> sk_acceptq_added() in vmci_transport_recv_listen(), no?
>
>Yes correct, vsock_add_pending() and sk_acceptq_added() stay in
>recv_listen(). vsock_pending_to_accept() only replaces the
>vsock_remove_pending() + vsock_enqueue_accept() calls in
>recv_connecting_server() once the handshake completes.
>
>So the v3 series will be 4 patches:
>  1/4: introduce vsock_pending_to_accept()
>  2/4: fold sk_acceptq_added() into vsock_add_pending()
>  3/4: fold sk_acceptq_added() into vsock_enqueue_accept() (virtio/hyperv)
>  4/4: fold sk_acceptq_removed() into vsock_remove_pending()

Okay, LGTM!

Stefano