From: "Michael S. Tsirkin" <mst@redhat.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Jason Wang <jasowang@redhat.com>,
virtualization@lists.osdl.org, netdev@vger.kernel.org,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/3] vhost-net: use lock_sock_fast() in peek_head_len()
Date: Sun, 13 Mar 2011 23:11:29 +0200 [thread overview]
Message-ID: <20110313211129.GA10235@redhat.com> (raw)
In-Reply-To: <1300038092.2761.41.camel@edumazet-laptop>
On Sun, Mar 13, 2011 at 06:41:32PM +0100, Eric Dumazet wrote:
> Le dimanche 13 mars 2011 à 18:43 +0200, Michael S. Tsirkin a écrit :
> > On Sun, Mar 13, 2011 at 05:32:07PM +0100, Eric Dumazet wrote:
> > > Le dimanche 13 mars 2011 à 18:19 +0200, Michael S. Tsirkin a écrit :
> > >
> > > > Other side is in drivers/net/tun.c and net/packet/af_packet.c
> > > > At least wrt tun it seems clear socket is not locked.
> > >
> > > Yes (assuming you refer to tun_net_xmit())
> > >
> > > > Besides queue, dequeue seems to be done without socket locked.
> > > >
> > >
> > > It seems this code (assuming you speak of drivers/vhost/net.c ?) has
> > > some races indeed.
> > >
> >
> > Hmm. Any more besides the one fixed here?
> >
>
> If writers and readers dont share a common lock, how can they reliably
> synchronize states ?
They are all supposed to use sk_receive_queue.lock I think.
> For example, the check at line 420 seems unsafe or useless.
>
> skb_queue_empty(&sock->sk->sk_receive_queue)
>
It's mostly useless: code that is called after this
does skb_peek and checks the result under the spinlock.
This was supposed to be an optimization: quickly check
that queue is not empty before we bother disabling notifications
etc, but I dont' remember at this point whether it actually gives any gain.
Thanks for pointing this out, I'll take it out I think (below).
Note: there are two places of this call in upstream: handle_rx_bug and
handle_rx_mergeable, but they are merged into a single
handle_rx by a patch by Jason Wang.
The below patch is on top.
If you like to look at the latest code,
it's here master.kernel.org:/home/mst/pub/vhost.git
branch vhost-net-next has it all.
Eric, thanks very much for pointing out these.
Is there anything else that you see in this driver?
Thanks!
vhost-net: remove unlocked use of receive_queue
Use of skb_queue_empty(&sock->sk->sk_receive_queue)
without taking the sk_receive_queue.lock is unsafe
or useless. Take it out.
Reported-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 5720301..2f7c76a 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -311,7 +311,7 @@ static void handle_rx(struct vhost_net *net)
/* TODO: check that we are running from vhost_worker? */
struct socket *sock = rcu_dereference_check(vq->private_data, 1);
- if (!sock || skb_queue_empty(&sock->sk->sk_receive_queue))
+ if (!sock)
return;
mutex_lock(&vq->mutex);
next prev parent reply other threads:[~2011-03-13 21:11 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-17 8:10 [PATCH 1/3] vhost-net: check the support of mergeable buffer outside the receive loop Jason Wang
2011-01-17 8:11 ` [PATCH 2/3] vhost-net: Unify the code of mergeable and big buffer handling Jason Wang
2011-01-17 8:36 ` Michael S. Tsirkin
2011-01-18 3:05 ` Jason Wang
2011-01-18 4:37 ` Michael S. Tsirkin
2011-01-18 7:41 ` Jason Wang
2011-01-17 8:11 ` [PATCH 3/3] vhost-net: use lock_sock_fast() in peek_head_len() Jason Wang
2011-01-17 9:33 ` Eric Dumazet
2011-01-17 9:33 ` Eric Dumazet
2011-01-17 9:57 ` Michael S. Tsirkin
2011-03-13 15:06 ` Michael S. Tsirkin
2011-03-13 15:52 ` Eric Dumazet
2011-03-13 16:19 ` Michael S. Tsirkin
2011-03-13 16:32 ` Eric Dumazet
2011-03-13 16:43 ` Michael S. Tsirkin
2011-03-13 17:41 ` Eric Dumazet
2011-03-13 21:11 ` Michael S. Tsirkin [this message]
2011-01-17 8:46 ` [PATCH 1/3] vhost-net: check the support of mergeable buffer outside the receive loop Michael S. Tsirkin
2011-01-18 4:26 ` Jason Wang
2011-01-18 4:36 ` Michael S. Tsirkin
2011-01-18 9:15 ` Jason Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110313211129.GA10235@redhat.com \
--to=mst@redhat.com \
--cc=eric.dumazet@gmail.com \
--cc=jasowang@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=virtualization@lists.osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.