From: Ed Swierk <eswierk@aristanetworks.com>
To: Sridhar Samudrala <sri@us.ibm.com>
Cc: arnd@arndb.de, netdev@vger.kernel.org
Subject: Re: [PATCH 0/3 v4] macvtap driver
Date: Mon, 08 Feb 2010 15:30:15 -0800 [thread overview]
Message-ID: <1265671815.6480.8.camel@localhost.localdomain> (raw)
In-Reply-To: <1265655334.31760.9.camel@w-sridhar.beaverton.ibm.com>
On Mon, 2010-02-08 at 10:55 -0800, 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.
Thanks, I tried your patch and it fixes the problem.
However, it seems to cause another minor problem. macvlan_count_rx() is
now getting called from macvtap_put_user() with preemption enabled,
which causes smp_processor_id() to BUG:
Feb 8 20:31:38 ti102 kernel: BUG: using smp_processor_id() in
preemptible [00000000] code: qemu-kvm/4546
Feb 8 20:31:38 ti102 kernel: caller is macvtap_aio_read+0x18c/0x221
[macvtap]
Feb 8 20:31:38 ti102 kernel: Pid: 4546, comm: qemu-kvm Not tainted
2.6.29.6.Ar-224686.2009eswierk8.2 #1
Feb 8 20:31:38 ti102 kernel: Call Trace:
Feb 8 20:31:38 ti102 kernel: [<c0349546>] ? printk+0xf/0x11
Feb 8 20:31:38 ti102 kernel: [<c02142c0>] debug_smp_processor_id
+0xa4/0xb8
Feb 8 20:31:38 ti102 kernel: [<f8af581f>] macvtap_aio_read+0x18c/0x221
[macvtap]
Feb 8 20:31:38 ti102 kernel: [<c011eaf7>] ? default_wake_function
+0x0/0xd
Feb 8 20:31:38 ti102 kernel: [<c016c75f>] do_sync_read+0xab/0xe9
Feb 8 20:31:38 ti102 kernel: [<c011933d>] ? update_curr+0x6c/0x147
Feb 8 20:31:38 ti102 kernel: [<c0133933>] ? autoremove_wake_function
+0x0/0x33
Feb 8 20:31:38 ti102 kernel: [<c0349fd0>] ? schedule+0x7af/0x7e3
Feb 8 20:31:38 ti102 kernel: [<c016d101>] vfs_read+0xb5/0x129
Feb 8 20:31:38 ti102 kernel: [<c016d20e>] sys_read+0x3b/0x60
Feb 8 20:31:38 ti102 kernel: [<c0102e71>] sysenter_do_call+0x12/0x25
I fixed this problem with the change below. I'm not sure if replacing
smp_processor_id() with get_cpu() is the right thing to do but it works
for macvtap at least.
Signed-off-by: Ed Swierk <eswierk@aristanetworks.com>
---
Index: linux-2.6.29.6/include/linux/if_macvlan.h
===================================================================
--- linux-2.6.29.6.orig/include/linux/if_macvlan.h
+++ linux-2.6.29.6/include/linux/if_macvlan.h
@@ -42,8 +42,9 @@ static inline void macvlan_count_rx(cons
bool multicast)
{
struct macvlan_rx_stats *rx_stats;
+ int cpu = get_cpu();
- rx_stats = per_cpu_ptr(vlan->rx_stats, smp_processor_id());
+ rx_stats = per_cpu_ptr(vlan->rx_stats, cpu);
if (likely(success)) {
rx_stats->rx_packets++;;
rx_stats->rx_bytes += len;
@@ -52,6 +53,7 @@ static inline void macvlan_count_rx(cons
} else {
rx_stats->rx_errors++;
}
+ put_cpu();
}
extern int macvlan_common_newlink(struct net_device *dev,
next prev parent reply other threads:[~2010-02-08 23:32 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 [this message]
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
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=1265671815.6480.8.camel@localhost.localdomain \
--to=eswierk@aristanetworks.com \
--cc=arnd@arndb.de \
--cc=netdev@vger.kernel.org \
--cc=sri@us.ibm.com \
/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 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).