* [PATCH net-next 2/3] vsock: fix vsock_dequeue/enqueue_accept race
@ 2017-08-15 22:15 Dexuan Cui
2017-08-17 12:43 ` Jorgen S. Hansen
2017-08-17 14:05 ` Stefan Hajnoczi
0 siblings, 2 replies; 5+ messages in thread
From: Dexuan Cui @ 2017-08-15 22:15 UTC (permalink / raw)
To: davem, netdev
Cc: 'gregkh, devel, KY Srinivasan, Haiyang Zhang,
Stephen Hemminger, George Zhang, Jorgen Hansen, Michal Kubecek,
Asias He, Stefan Hajnoczi, Vitaly Kuznetsov, Cathy Avery,
jasowang, Rolf Neugebauer, Dave Scott, Marcelo Cerri, apw, olaf,
joe, linux-kernel, Dan Carpenter
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
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH net-next 2/3] vsock: fix vsock_dequeue/enqueue_accept race
2017-08-15 22:15 [PATCH net-next 2/3] vsock: fix vsock_dequeue/enqueue_accept race Dexuan Cui
@ 2017-08-17 12:43 ` Jorgen S. Hansen
2017-08-18 0:37 ` Dexuan Cui
2017-08-17 14:05 ` Stefan Hajnoczi
1 sibling, 1 reply; 5+ messages in thread
From: Jorgen S. Hansen @ 2017-08-17 12:43 UTC (permalink / raw)
To: Dexuan Cui
Cc: davem, netdev, gregkh, devel, KY Srinivasan, Haiyang Zhang,
Stephen Hemminger, George Zhang, Michal Kubecek, Asias He,
Stefan Hajnoczi, Vitaly Kuznetsov, Cathy Avery, jasowang,
Rolf Neugebauer, Dave Scott, Marcelo Cerri, apw, olaf, joe,
linux-kernel, Dan Carpenter
> 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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH net-next 2/3] vsock: fix vsock_dequeue/enqueue_accept race
2017-08-15 22:15 [PATCH net-next 2/3] vsock: fix vsock_dequeue/enqueue_accept race Dexuan Cui
2017-08-17 12:43 ` Jorgen S. Hansen
@ 2017-08-17 14:05 ` Stefan Hajnoczi
2017-08-18 21:13 ` Dexuan Cui
1 sibling, 1 reply; 5+ messages in thread
From: Stefan Hajnoczi @ 2017-08-17 14:05 UTC (permalink / raw)
To: Dexuan Cui
Cc: davem, netdev, devel, KY Srinivasan, Haiyang Zhang,
Stephen Hemminger, George Zhang, Jorgen Hansen, Michal Kubecek,
Vitaly Kuznetsov, Cathy Avery, jasowang, Rolf Neugebauer,
Dave Scott, Marcelo Cerri, apw, olaf, joe, linux-kernel,
Dan Carpenter
[-- Attachment #1: Type: text/plain, Size: 474 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: [PATCH net-next 2/3] vsock: fix vsock_dequeue/enqueue_accept race
2017-08-17 12:43 ` Jorgen S. Hansen
@ 2017-08-18 0:37 ` Dexuan Cui
0 siblings, 0 replies; 5+ messages in thread
From: Dexuan Cui @ 2017-08-18 0:37 UTC (permalink / raw)
To: Jorgen S. Hansen, davem
Cc: netdev, gregkh, devel, KY Srinivasan, Haiyang Zhang,
Stephen Hemminger, George Zhang, Michal Kubecek, Stefan Hajnoczi,
Vitaly Kuznetsov, Cathy Avery, jasowang, Rolf Neugebauer,
Dave Scott, Marcelo Cerri, apw, olaf, joe, linux-kernel,
Dan Carpenter
> > 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.
>
> Jorgen
Hi Jorgen,
Thanks, you're correct.
Please ignore this patch. I'll update the hv_sock driver to add proper
lock_sock()/relesae_sock().
Thanks,
-- Dexuan
^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: [PATCH net-next 2/3] vsock: fix vsock_dequeue/enqueue_accept race
2017-08-17 14:05 ` Stefan Hajnoczi
@ 2017-08-18 21:13 ` Dexuan Cui
0 siblings, 0 replies; 5+ messages in thread
From: Dexuan Cui @ 2017-08-18 21:13 UTC (permalink / raw)
To: Stefan Hajnoczi
Cc: davem, netdev, devel, KY Srinivasan, Haiyang Zhang,
Stephen Hemminger, George Zhang, Jorgen Hansen, Michal Kubecek,
Vitaly Kuznetsov, Cathy Avery, jasowang, Rolf Neugebauer,
Dave Scott, Marcelo Cerri, apw, olaf, joe, linux-kernel,
Dan Carpenter
> From: Stefan Hajnoczi [mailto:stefanha@redhat.com]
> Sent: Thursday, August 17, 2017 07:06
>
> 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
Sorry, I was not careful when checking the vmci code.
Please ignore the patch.
Now I realized the expectation is that the individual transport drivers should
do the locking for vsock_enqueue_accept(), but for vsock_dequeue_accept(),
the locking is done by the common vsock driver.
Thanks,
-- Dexuan
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2017-08-18 21:13 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-08-15 22:15 [PATCH net-next 2/3] vsock: fix vsock_dequeue/enqueue_accept race Dexuan Cui
2017-08-17 12:43 ` Jorgen S. Hansen
2017-08-18 0:37 ` Dexuan Cui
2017-08-17 14:05 ` Stefan Hajnoczi
2017-08-18 21:13 ` Dexuan Cui
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).