From: Arnd Bergmann <arnd@arndb•de>
To: Sridhar Samudrala <sri@us•ibm.com>
Cc: Ed Swierk <eswierk@aristanetworks•com>, netdev@vger•kernel.org
Subject: Re: [PATCH 0/3 v4] macvtap driver
Date: Wed, 10 Feb 2010 15:48:47 +0100 [thread overview]
Message-ID: <201002101548.47634.arnd@arndb.de> (raw)
In-Reply-To: <1265655334.31760.9.camel@w-sridhar.beaverton.ibm.com>
On Monday 08 February 2010, Sridhar Samudrala wrote:
> I am also seeing this issue with net-next-2.6.
> Basically macvtap_put_user() and macvtap_get_user() call copy_to/from_user
> from within a RCU read-side critical section.
>
> The following patch fixes this issue by releasing the RCU read lock before
> calling these routines, but instead hold a reference to q->sk.
>
> Signed-off-by: Sridhar Samudrala <sri@us•ibm.com>
Yes, we need something like this, but we also need to protect the
device from going away. The concept right now is to use file_get_queue
to protect both the macvtap_queue and the macvlan_dev from going
away. The sock_hold will keep the macvtap_queue around, but
as far as I can tell, a user could still destroy the macvlan_dev
using netlink at the same time, which still breaks.
> /* Get packet from user space buffer */
> -static ssize_t macvtap_get_user(struct macvtap_queue *q,
> +static ssize_t macvtap_get_user(struct macvlan_dev *vlan, struct sock *sk,
> const struct iovec *iv, size_t count,
> int noblock)
> {
> @@ -331,10 +331,10 @@ static ssize_t macvtap_get_user(struct macvtap_queue *q,
> if (unlikely(len < ETH_HLEN))
> return -EINVAL;
>
> - skb = sock_alloc_send_skb(&q->sk, NET_IP_ALIGN + len, noblock, &err);
> + skb = sock_alloc_send_skb(sk, NET_IP_ALIGN + len, noblock, &err);
>
> if (!skb) {
> - macvlan_count_rx(q->vlan, 0, false, false);
> + macvlan_count_rx(vlan, 0, false, false);
> return err;
> }
>
> @@ -342,14 +342,14 @@ static ssize_t macvtap_get_user(struct macvtap_queue *q,
> skb_put(skb, count);
>
> if (skb_copy_datagram_from_iovec(skb, 0, iv, 0, len)) {
> - macvlan_count_rx(q->vlan, 0, false, false);
> + macvlan_count_rx(vlan, 0, false, false);
> kfree_skb(skb);
> return -EFAULT;
> }
>
> skb_set_network_header(skb, ETH_HLEN);
>
> - macvlan_start_xmit(skb, q->vlan->dev);
> + macvlan_start_xmit(skb, vlan->dev);
>
> return count;
> }
What are these changes for? The lifetime of q is the same as &q->sk, so
it won't change anything, right?
Moving the macvlan_count_rx and maxclan_start_xmit under the lock
should be fine though, but we'd have to take it twice then for
each transmit.
I'd hope that this could get simpler by adding zero-copy transmit,
where we first get_user() the whole buffer and do the rest under
rcu_read_lock_bh().
> @@ -393,15 +399,20 @@ static ssize_t macvtap_aio_read(struct kiocb *iocb, const struct iovec *iv,
> {
> struct file *file = iocb->ki_filp;
> struct macvtap_queue *q = macvtap_file_get_queue(file);
> + struct macvlan_dev *vlan;
> + struct sock *sk;
>
> DECLARE_WAITQUEUE(wait, current);
> struct sk_buff *skb;
> ssize_t len, ret = 0;
>
> - if (!q) {
> - ret = -ENOLINK;
> - goto out;
> - }
> + if (!q)
> + return -ENOLINK;
> +
> + vlan = q->vlan;
> + sk = &q->sk;
> + sock_hold(sk);
> + macvtap_file_put_queue();
Here, we probably need to prevent vlan from going away by dev_hold(),
not just sock_hold(). Or is one implied by the other?
Arnd
next prev parent reply other threads:[~2010-02-10 14:49 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-27 10:04 [PATCH 0/3 v3] macvtap driver Arnd Bergmann
2010-01-27 10:05 ` [PATCH 1/3] net: maintain namespace isolation between vlan and real device Arnd Bergmann
2010-01-29 5:33 ` David Miller
2010-01-29 10:12 ` Arnd Bergmann
2010-01-27 10:06 ` [PATCH 2/3] net/macvlan: allow multiple driver backends Arnd Bergmann
2010-01-27 21:09 ` [PATCH 3/3] net: macvtap driver Arnd Bergmann
2010-01-28 17:34 ` Michael S. Tsirkin
2010-01-28 20:18 ` Arnd Bergmann
2010-01-29 11:21 ` Michael S. Tsirkin
2010-01-29 19:49 ` Arnd Bergmann
2010-01-27 21:59 ` [PATCH 0/3 v3] " Arnd Bergmann
2010-01-30 22:22 ` [PATCH 0/3 v4] " Arnd Bergmann
2010-01-30 22:23 ` [PATCH 1/3] net: maintain namespace isolation between vlan and real device Arnd Bergmann
2010-01-30 22:23 ` [PATCH 2/3] macvlan: allow multiple driver backends Arnd Bergmann
2010-01-30 22:24 ` [PATCH 3/3] net: macvtap driver Arnd Bergmann
2010-02-04 4:21 ` [PATCH 0/3 v4] " David Miller
2010-02-08 17:14 ` Ed Swierk
2010-02-08 18:55 ` Sridhar Samudrala
2010-02-08 23:30 ` Ed Swierk
2010-02-10 14:50 ` Arnd Bergmann
2010-02-11 0:42 ` Ed Swierk
2010-02-11 7:12 ` Arnd Bergmann
2010-02-09 3:25 ` Ed Swierk
2010-02-10 14:52 ` Arnd Bergmann
2010-02-10 14:48 ` Arnd Bergmann [this message]
2010-02-10 18:05 ` Sridhar Samudrala
2010-02-10 18:10 ` Patrick McHardy
2010-02-11 15:45 ` [PATCH] net/macvtap: fix reference counting Arnd Bergmann
2010-02-11 15:55 ` [PATCH v2] " Arnd Bergmann
2010-02-11 21:09 ` Sridhar Samudrala
2010-02-16 5:53 ` David Miller
2010-02-18 15:44 ` Arnd Bergmann
2010-02-18 15:45 ` [PATCH 1/3] macvtap: rework object lifetime rules Arnd Bergmann
2010-02-18 20:09 ` Sridhar Samudrala
2010-02-18 22:11 ` David Miller
2010-02-18 15:46 ` [PATCH 2/3] net/macvtap: add vhost support Arnd Bergmann
2010-02-18 20:10 ` Sridhar Samudrala
2010-02-18 22:11 ` David Miller
2010-02-18 15:48 ` [PATCH 3/3] macvtap: add GSO/csum offload support Arnd Bergmann
2010-02-18 20:38 ` Sridhar Samudrala
2010-02-18 22:11 ` David Miller
2010-02-12 20:58 ` [PATCH v2] net/macvtap: fix reference counting Ed Swierk
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=201002101548.47634.arnd@arndb.de \
--to=arnd@arndb$(echo .)de \
--cc=eswierk@aristanetworks$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=sri@us$(echo .)ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox