Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1712499 > unrolled thread

[PATCH net-next 2/3] vsock: fix vsock_dequeue/enqueue_accept race

Back to article view | Back to linux.kernel

Contents

  [PATCH net-next 2/3] vsock: fix vsock_dequeue/enqueue_accept race Dexuan Cui <decui@microsoft.com> - 2017-08-16 00:20 +0200
    Re: [PATCH net-next 2/3] vsock: fix vsock_dequeue/enqueue_accept race "Jorgen S. Hansen" <jhansen@vmware.com> - 2017-08-17 14:50 +0200
    Re: [PATCH net-next 2/3] vsock: fix vsock_dequeue/enqueue_accept race Stefan Hajnoczi <stefanha@redhat.com> - 2017-08-18 18:00 +0200

#1712499 — [PATCH net-next 2/3] vsock: fix vsock_dequeue/enqueue_accept race

With the current code, when vsock_dequeue_accept() is removing a sock
from the list, nothing prevents vsock_enqueue_accept() from adding a new
sock into the list concurrently. We should add a lock to protect the list.

Signed-off-by: Dexuan Cui <decui@microsoft.com>
Cc: Andy King <acking@vmware.com>
Cc: Dmitry Torokhov <dtor@vmware.com>
Cc: George Zhang <georgezhang@vmware.com>
Cc: Jorgen Hansen <jhansen@vmware.com>
Cc: Reilly Grant <grantr@vmware.com>
Cc: Asias He <asias@redhat.com>
Cc: Stefan Hajnoczi <stefanha@redhat.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: Cathy Avery <cavery@redhat.com>
Cc: K. Y. Srinivasan <kys@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Stephen Hemminger <sthemmin@microsoft.com>
---
 net/vmw_vsock/af_vsock.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index dfc8c51e..b7b2c66 100644
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -126,6 +126,7 @@ static struct proto vsock_proto = {
 
 static const struct vsock_transport *transport;
 static DEFINE_MUTEX(vsock_register_mutex);
+static DEFINE_SPINLOCK(vsock_accept_queue_lock);
 
 /**** EXPORTS ****/
 
@@ -406,7 +407,10 @@ void vsock_enqueue_accept(struct sock *listener, struct sock *connected)
 
 	sock_hold(connected);
 	sock_hold(listener);
+
+	spin_lock(&vsock_accept_queue_lock);
 	list_add_tail(&vconnected->accept_queue, &vlistener->accept_queue);
+	spin_unlock(&vsock_accept_queue_lock);
 }
 EXPORT_SYMBOL_GPL(vsock_enqueue_accept);
 
@@ -423,7 +427,10 @@ static struct sock *vsock_dequeue_accept(struct sock *listener)
 	vconnected = list_entry(vlistener->accept_queue.next,
 				struct vsock_sock, accept_queue);
 
+	spin_lock(&vsock_accept_queue_lock);
 	list_del_init(&vconnected->accept_queue);
+	spin_unlock(&vsock_accept_queue_lock);
+
 	sock_put(listener);
 	/* The caller will need a reference on the connected socket so we let
 	 * it call sock_put().
-- 
2.7.4

[toc] | [next] | [standalone]

#1713973

> On Aug 16, 2017, at 12:15 AM, Dexuan Cui <decui@microsoft.com> wrote:
> 
> 
> With the current code, when vsock_dequeue_accept() is removing a sock
> from the list, nothing prevents vsock_enqueue_accept() from adding a new
> sock into the list concurrently. We should add a lock to protect the list.
> 

For the VMCI socket transport, we always lock the sockets before calling into vsock_enqueue_accept and af_vsock.c locks the socket before calling vsock_dequeue_accept, so from our point of view these operations are already protected, but with finer granularity than a single global lock. As far as I can see, the virtio transport also locks the socket before calling vsock_enqueue_accept, so they should be fine with the current version as well, but Stefan can comment on that.

Thanks,
Jorgen

[toc] | [prev] | [next] | [standalone]

#1715276

[Multipart message — attachments visible in raw view] — view raw

On Tue, Aug 15, 2017 at 10:15:39PM +0000, Dexuan Cui wrote:
> With the current code, when vsock_dequeue_accept() is removing a sock
> from the list, nothing prevents vsock_enqueue_accept() from adding a new
> sock into the list concurrently. We should add a lock to protect the list.

The listener sock is locked, preventing concurrent modification.  I have
checked both the virtio and vmci transports.  Can you post an example
where the listener sock isn't locked?

Stefan

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web