* Re: [slab poison overwritten] Re: [GIT] Networking
From: Simon Horman @ 2011-03-22 0:17 UTC (permalink / raw)
To: Eric Dumazet
Cc: Ingo Molnar, David Miller, torvalds, akpm, netdev, linux-kernel,
Peter Zijlstra, Thomas Gleixner, Arnd Bergmann, Pekka Enberg,
Julian Anastasov, Hans Schillstrom
In-Reply-To: <20110322000130.GC27019@verge.net.au>
On Tue, Mar 22, 2011 at 09:01:33AM +0900, Simon Horman wrote:
> On Tue, Mar 22, 2011 at 08:29:21AM +0900, Simon Horman wrote:
> > On Tue, Mar 22, 2011 at 07:13:58AM +0900, Simon Horman wrote:
> > > On Mon, Mar 21, 2011 at 09:15:40PM +0100, Eric Dumazet wrote:
> > > > Le lundi 21 mars 2011 à 19:07 +0100, Eric Dumazet a écrit :
> > > > > Le lundi 21 mars 2011 à 18:39 +0100, Ingo Molnar a écrit :
> > > > > > here's the same but with kallsyms enabled.
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Ingo
> > > > > >
> > > > > > [ 9.585627] initcall 0xffffffff81d5b806 returned 0 after 0 usecs
> > > > > > [ 9.588960] calling 0xffffffff81d5b9da @ 1
> > > > > > [ 9.592303] IPVS: Creating netns size=1272 id=0
> > > > > > [ 9.595646] IPVS: __ip_vs_control_init(): alloc_percpu.
> > > > > > [ 9.602298] IPVS: cannot register namespace.
> > > > > > [ 9.605627] IPVS: can't setup control
> > > > >
> > > > > It seems IPVS is busted in case of memory allocation error in
> > > > > __ip_vs_control_init()
> > > > >
> > > > > IPVS deinits its "struct netns_ipvs" space, but something (in IPVS) uses
> > > > > it after free.
> > > > >
> > > > > __ip_vs_init() seems to be called before ip_vs_init() completes
> > > > > correctly. We then keep in net->ipvs a pointer to some freed memory.
> > > > >
> > > > > Commit 14e405461e664b7 did some changes in this area
> > > > >
> > > > > Simon, any idea ?
> > > > >
> > > > >
> > > >
> > > > For the time being, we can avoid the false memory allocation error (and
> > > > leak)
> > >
> > > Sorry, that typo is my work.
> >
> > With your patch applied I now see the following
> >
> > ffff880003bbf1a0 corresponds to &ipvs->app_key in __ip_vs_app_init().
> > I'll continue looking into this.
> >
> > [ 12.610000] IPVS: Creating netns size=2456 id=0
> > [ 12.630000] IPVS: Registered protocols (TCP, UDP, SCTP, AH, ESP)
> > [ 12.640000] BUG: key ffff880003bbf1a0 not in .data!
> > [ 12.640000] ------------[ cut here ]------------
> > [ 12.640000] WARNING: at kernel/lockdep.c:2701
> > lockdep_init_map+0x37b/0x570()
> > [ 12.640000] Hardware name: Bochs
> > [ 12.640000] Pid: 1, comm: swapper Tainted: G W
> > 2.6.38-kexec-06330-g69b7efe-dirty #122
> > [ 12.650000] Call Trace:
> > [ 12.650000] [<ffffffff8102e685>] warn_slowpath_common+0x75/0xb0
> > [ 12.650000] [<ffffffff8102e6d5>] warn_slowpath_null+0x15/0x20
> > [ 12.650000] [<ffffffff8105967b>] lockdep_init_map+0x37b/0x570
> > [ 12.650000] [<ffffffff8105829d>] ? trace_hardirqs_on+0xd/0x10
> > [ 12.650000] [<ffffffff81055ad8>] debug_mutex_init+0x38/0x50
> > [ 12.650000] [<ffffffff8104bc4c>] __mutex_init+0x5c/0x70
> > [ 12.650000] [<ffffffff81685ee7>] __ip_vs_app_init+0x64/0x86
> > [ 12.660000] [<ffffffff81685a3b>] ? ip_vs_init+0x0/0xff
> > [ 12.660000] [<ffffffff811b1c33>] T.620+0x43/0x170
> > [ 12.660000] [<ffffffff811b1e9a>] ? register_pernet_subsys+0x1a/0x40
> > [ 12.660000] [<ffffffff81685a3b>] ? ip_vs_init+0x0/0xff
> > [ 12.660000] [<ffffffff81685a3b>] ? ip_vs_init+0x0/0xff
> > [ 12.660000] [<ffffffff811b1db7>] register_pernet_operations+0x57/0xb0
> > [ 12.660000] [<ffffffff81685a3b>] ? ip_vs_init+0x0/0xff
> > [ 12.670000] [<ffffffff811b1ea9>] register_pernet_subsys+0x29/0x40
> > [ 12.670000] [<ffffffff81685f19>] ip_vs_app_init+0x10/0x12
> > [ 12.670000] [<ffffffff81685a87>] ip_vs_init+0x4c/0xff
> > [ 12.670000] [<ffffffff8166562c>] do_one_initcall+0x7a/0x12e
> > [ 12.670000] [<ffffffff8166583e>] kernel_init+0x13e/0x1c2
> > [ 12.670000] [<ffffffff8128c134>] kernel_thread_helper+0x4/0x10
> > [ 12.670000] [<ffffffff8128ad40>] ? restore_args+0x0/0x30
> > [ 12.680000] [<ffffffff81665700>] ? kernel_init+0x0/0x1c2
> > [ 12.680000] [<ffffffff8128c130>] ? kernel_thread_helper+0x0/0x10
> > [ 12.680000] ---[ end trace 4eaa2a86a8e2da23 ]---
>
> It seems that the problem above was introduced by
> ab8a5e8408c3 ("IPVS: netns awareness to ip_vs_app").
> I assume the hungs are the cause:
s/hungs/hunks below/
I am a little unsure of what to do about this.
The problem seems to be that ipvs->app_key is not in static storage.
But I'm not sure how to resolve that given that the struct netns_ipvs is
per-network namespace. So I guess that the locking needs to be re-worked.
Again, I'm a little unsure of what the best way forward is.
> diff --git a/net/netfilter/ipvs/ip_vs_app.c b/net/netfilter/ipvs/ip_vs_app.c
> index 40b09cc..286f465 100644
> --- a/net/netfilter/ipvs/ip_vs_app.c
> +++ b/net/netfilter/ipvs/ip_vs_app.c
> @@ -43,11 +43,6 @@ EXPORT_SYMBOL(register_ip_vs_app);
> EXPORT_SYMBOL(unregister_ip_vs_app);
> EXPORT_SYMBOL(register_ip_vs_app_inc);
>
> -/* ipvs application list head */
> -static LIST_HEAD(ip_vs_app_list);
> -static DEFINE_MUTEX(__ip_vs_app_mutex);
> -
> -
> /*
> * Get an ip_vs_app object
> */
>
> @@ -571,9 +580,13 @@ static const struct file_operations ip_vs_app_fops = {
>
> static int __net_init __ip_vs_app_init(struct net *net)
> {
> + struct netns_ipvs *ipvs = net_ipvs(net);
> +
> if (!net_eq(net, &init_net)) /* netns not enabled yet */
> return -EPERM;
>
> + INIT_LIST_HEAD(&ipvs->app_list);
> + __mutex_init(&ipvs->app_mutex, "ipvs->app_mutex", &ipvs->app_key);
> proc_net_fops_create(net, "ip_vs_app", 0, &ip_vs_app_fops);
> return 0;
> }
^ permalink raw reply
* Re: ipv6 secondary ips and default ipv6 ip for new outbound connections
From: Jim Westfall @ 2011-03-22 0:15 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Brian Haley, netdev
In-Reply-To: <m2k4fvbks6.fsf@igel.home>
Andreas Schwab <schwab@linux-m68k.org> wrote [03.19.11]:
> Jim Westfall <jwestfall@surrealistic.net> writes:
>
> > Your patch fixes it for me.
> >
> > # ip addr add 2600:c00:0:1::1101/64 dev eth0
> > ~# traceroute6 www.kame.net | head -0
> > traceroute to orange.kame.net (2001:200:dff:fff1:216:3eff:feb1:44d7) from 2600:c00:0:1::1101, 30 hops max, 16 byte packets
> >
> > ~# ip addr add 2600:c00:0:1::1102/64 dev eth0
> > ~# traceroute6 www.kame.net | head -0
> > traceroute to orange.kame.net (2001:200:dff:fff1:216:3eff:feb1:44d7) from 2600:c00:0:1::1101, 30 hops max, 16 byte packets
> >
> > ~# ip addr add 2600:c00:0:1::1103/64 dev eth0
> > ~# traceroute6 www.kame.net | head -0
> > traceroute to orange.kame.net (2001:200:dff:fff1:216:3eff:feb1:44d7) from 2600:c00:0:1::1101, 30 hops max, 16 byte packets
>
> Does this also affect the selected address if use_tempaddr=2?
>
> Andreas.
>
I am new to using temp addresses, but it appears to be working as
expected.
With the interface down I set use_tempaddr=2, brought the interface up
and added my 2 static ipv6 ips, then ran rdisc6 on the interface.
This resulted in the following
13: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
link/ether 00:10:18:17:a0:e6 brd ff:ff:ff:ff:ff:ff
inet6 2600:c00:1002:2::101/64 scope global
valid_lft forever preferred_lft forever
inet6 2600:c00:1002:2::102/64 scope global
valid_lft forever preferred_lft forever
inet6 2600:c00:1002:2:210:18ff:fe17:a0e6/64 scope global dynamic
valid_lft 2591996sec preferred_lft 604796sec
inet6 2600:c00:1002:2:ccd2:cf82:efb0:8dc5/64 scope global temporary dynamic
valid_lft 604796sec preferred_lft 85796sec
inet6 fe80::210:18ff:fe17:a0e6/64 scope link
valid_lft forever preferred_lft forever
~# traceroute6 www.kame.net
traceroute to orange.kame.net (2001:200:dff:fff1:216:3eff:feb1:44d7) from 2600:c00:1002:2:ccd2:cf82:efb0:8dc5, 30 hops max, 16 byte packets
It correctly sourced from 2600:c00:1002:2:ccd2:cf82:efb0:8dc5.
I repeated the same steps but reset use_tempaddr=1
~# traceroute6 www.kame.net
traceroute to orange.kame.net (2001:200:dff:fff1:216:3eff:feb1:44d7) from 2600:c00:1002:2::101, 30 hops max, 16 byte packets
For which 2600:c00:1002:2::101 was my first added static ip.
In testing the above I observed that downing the interface resulted in
all ipv6 addressing being removed. Is this expected? I can see
removing the dynamic/temp addresses, but seems weird for the statics I
added.
thanks
Jim
^ permalink raw reply
* Re: [PATCH][v3] dev : fix mtu check when TSO is enabled
From: Michał Mirosław @ 2011-03-22 0:05 UTC (permalink / raw)
To: David Miller; +Cc: daniel.lezcano, eric.dumazet, kaber, nightnord, netdev
In-Reply-To: <20110314.165929.232913682.davem@davemloft.net>
2011/3/15 David Miller <davem@davemloft.net>:
> From: Daniel Lezcano <daniel.lezcano@free.fr>
> Date: Mon, 14 Mar 2011 21:39:50 +0100
>> +
>> + /* if TSO is enabled, we don't care about the length as the packet
>> + * could be forwarded without being segmented before
>> + */
>> + if (skb->dev && skb->dev->features & NETIF_F_TSO)
>> + return true;
> I am trying to understand why you aren't simply checking also if this
> is a segmented frame? Perhaps skb_is_gso() && device has NETIF_F_TSO
> set?
Is the check of netdev features even necessary? Devices without TSO
enabled the skbs are segmented before ndo_start_xmit() anyway.
With TSO there's a question if the receiving end of macvlan can handle
GRO/LRO packets?
BTW, checking only NETIF_F_TSO will break at least for IPv6 TSO
(NETIF_F_TSO6) or whatever else can be segmented in hardware.
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: [slab poison overwritten] Re: [GIT] Networking
From: Simon Horman @ 2011-03-22 0:01 UTC (permalink / raw)
To: Eric Dumazet
Cc: Ingo Molnar, David Miller, torvalds, akpm, netdev, linux-kernel,
Peter Zijlstra, Thomas Gleixner, Arnd Bergmann, Pekka Enberg,
Julian Anastasov, Hans Schillstrom
In-Reply-To: <20110321232921.GG22625@verge.net.au>
On Tue, Mar 22, 2011 at 08:29:21AM +0900, Simon Horman wrote:
> On Tue, Mar 22, 2011 at 07:13:58AM +0900, Simon Horman wrote:
> > On Mon, Mar 21, 2011 at 09:15:40PM +0100, Eric Dumazet wrote:
> > > Le lundi 21 mars 2011 à 19:07 +0100, Eric Dumazet a écrit :
> > > > Le lundi 21 mars 2011 à 18:39 +0100, Ingo Molnar a écrit :
> > > > > here's the same but with kallsyms enabled.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Ingo
> > > > >
> > > > > [ 9.585627] initcall 0xffffffff81d5b806 returned 0 after 0 usecs
> > > > > [ 9.588960] calling 0xffffffff81d5b9da @ 1
> > > > > [ 9.592303] IPVS: Creating netns size=1272 id=0
> > > > > [ 9.595646] IPVS: __ip_vs_control_init(): alloc_percpu.
> > > > > [ 9.602298] IPVS: cannot register namespace.
> > > > > [ 9.605627] IPVS: can't setup control
> > > >
> > > > It seems IPVS is busted in case of memory allocation error in
> > > > __ip_vs_control_init()
> > > >
> > > > IPVS deinits its "struct netns_ipvs" space, but something (in IPVS) uses
> > > > it after free.
> > > >
> > > > __ip_vs_init() seems to be called before ip_vs_init() completes
> > > > correctly. We then keep in net->ipvs a pointer to some freed memory.
> > > >
> > > > Commit 14e405461e664b7 did some changes in this area
> > > >
> > > > Simon, any idea ?
> > > >
> > > >
> > >
> > > For the time being, we can avoid the false memory allocation error (and
> > > leak)
> >
> > Sorry, that typo is my work.
>
> With your patch applied I now see the following
>
> ffff880003bbf1a0 corresponds to &ipvs->app_key in __ip_vs_app_init().
> I'll continue looking into this.
>
> [ 12.610000] IPVS: Creating netns size=2456 id=0
> [ 12.630000] IPVS: Registered protocols (TCP, UDP, SCTP, AH, ESP)
> [ 12.640000] BUG: key ffff880003bbf1a0 not in .data!
> [ 12.640000] ------------[ cut here ]------------
> [ 12.640000] WARNING: at kernel/lockdep.c:2701
> lockdep_init_map+0x37b/0x570()
> [ 12.640000] Hardware name: Bochs
> [ 12.640000] Pid: 1, comm: swapper Tainted: G W
> 2.6.38-kexec-06330-g69b7efe-dirty #122
> [ 12.650000] Call Trace:
> [ 12.650000] [<ffffffff8102e685>] warn_slowpath_common+0x75/0xb0
> [ 12.650000] [<ffffffff8102e6d5>] warn_slowpath_null+0x15/0x20
> [ 12.650000] [<ffffffff8105967b>] lockdep_init_map+0x37b/0x570
> [ 12.650000] [<ffffffff8105829d>] ? trace_hardirqs_on+0xd/0x10
> [ 12.650000] [<ffffffff81055ad8>] debug_mutex_init+0x38/0x50
> [ 12.650000] [<ffffffff8104bc4c>] __mutex_init+0x5c/0x70
> [ 12.650000] [<ffffffff81685ee7>] __ip_vs_app_init+0x64/0x86
> [ 12.660000] [<ffffffff81685a3b>] ? ip_vs_init+0x0/0xff
> [ 12.660000] [<ffffffff811b1c33>] T.620+0x43/0x170
> [ 12.660000] [<ffffffff811b1e9a>] ? register_pernet_subsys+0x1a/0x40
> [ 12.660000] [<ffffffff81685a3b>] ? ip_vs_init+0x0/0xff
> [ 12.660000] [<ffffffff81685a3b>] ? ip_vs_init+0x0/0xff
> [ 12.660000] [<ffffffff811b1db7>] register_pernet_operations+0x57/0xb0
> [ 12.660000] [<ffffffff81685a3b>] ? ip_vs_init+0x0/0xff
> [ 12.670000] [<ffffffff811b1ea9>] register_pernet_subsys+0x29/0x40
> [ 12.670000] [<ffffffff81685f19>] ip_vs_app_init+0x10/0x12
> [ 12.670000] [<ffffffff81685a87>] ip_vs_init+0x4c/0xff
> [ 12.670000] [<ffffffff8166562c>] do_one_initcall+0x7a/0x12e
> [ 12.670000] [<ffffffff8166583e>] kernel_init+0x13e/0x1c2
> [ 12.670000] [<ffffffff8128c134>] kernel_thread_helper+0x4/0x10
> [ 12.670000] [<ffffffff8128ad40>] ? restore_args+0x0/0x30
> [ 12.680000] [<ffffffff81665700>] ? kernel_init+0x0/0x1c2
> [ 12.680000] [<ffffffff8128c130>] ? kernel_thread_helper+0x0/0x10
> [ 12.680000] ---[ end trace 4eaa2a86a8e2da23 ]---
It seems that the problem above was introduced by
ab8a5e8408c3 ("IPVS: netns awareness to ip_vs_app").
I assume the hungs are the cause:
diff --git a/net/netfilter/ipvs/ip_vs_app.c b/net/netfilter/ipvs/ip_vs_app.c
index 40b09cc..286f465 100644
--- a/net/netfilter/ipvs/ip_vs_app.c
+++ b/net/netfilter/ipvs/ip_vs_app.c
@@ -43,11 +43,6 @@ EXPORT_SYMBOL(register_ip_vs_app);
EXPORT_SYMBOL(unregister_ip_vs_app);
EXPORT_SYMBOL(register_ip_vs_app_inc);
-/* ipvs application list head */
-static LIST_HEAD(ip_vs_app_list);
-static DEFINE_MUTEX(__ip_vs_app_mutex);
-
-
/*
* Get an ip_vs_app object
*/
@@ -571,9 +580,13 @@ static const struct file_operations ip_vs_app_fops = {
static int __net_init __ip_vs_app_init(struct net *net)
{
+ struct netns_ipvs *ipvs = net_ipvs(net);
+
if (!net_eq(net, &init_net)) /* netns not enabled yet */
return -EPERM;
+ INIT_LIST_HEAD(&ipvs->app_list);
+ __mutex_init(&ipvs->app_mutex, "ipvs->app_mutex", &ipvs->app_key);
proc_net_fops_create(net, "ip_vs_app", 0, &ip_vs_app_fops);
return 0;
}
^ permalink raw reply related
* [SECURITY] DECnet: need to validate user data and access data?
From: Dan Rosenberg @ 2011-03-21 23:41 UTC (permalink / raw)
To: davem; +Cc: security, netdev
In net/decnet/af_decnet.c, in the dn_access_copy() and dn_user_copy()
functions, which are called from dn_connect(), length values are
retrieved from incoming skb data and used as size values to copy
functions:
static void dn_access_copy(struct sk_buff *skb, struct accessdata_dn *acc)
{
unsigned char *ptr = skb->data;
acc->acc_userl = *ptr++;
memcpy(&acc->acc_user, ptr, acc->acc_userl);
ptr += acc->acc_userl;
acc->acc_passl = *ptr++;
memcpy(&acc->acc_pass, ptr, acc->acc_passl);
ptr += acc->acc_passl;
acc->acc_accl = *ptr++;
memcpy(&acc->acc_acc, ptr, acc->acc_accl);
skb_pull(skb, acc->acc_accl + acc->acc_passl + acc->acc_userl + 3);
}
static void dn_user_copy(struct sk_buff *skb, struct optdata_dn *opt)
{
unsigned char *ptr = skb->data;
u16 len = *ptr++; /* yes, it's 8bit on the wire */
BUG_ON(len > 16); /* we've checked the contents earlier */
opt->opt_optl = cpu_to_le16(len);
opt->opt_status = 0;
memcpy(opt->opt_data, ptr, len);
skb_pull(skb, len + 1);
}
Despite the BUG_ON and comment suggesting these lengths have been
validated, I don't think this is actually the case - it looks like these
fields are validated for outbound data, but I see no validation for
inbound data (unless I'm mistaken, which is entirely possible). If this
is the case, this can allow remote attackers to cause controllable heap
corruption. I'd appreciate it if someone who knows this protocol better
than I do took a look at this and implemented appropriate error handling
if it needs it.
Thanks,
Dan
^ permalink raw reply
* Re: [slab poison overwritten] Re: [GIT] Networking
From: Simon Horman @ 2011-03-21 23:29 UTC (permalink / raw)
To: Eric Dumazet
Cc: Ingo Molnar, David Miller, torvalds, akpm, netdev, linux-kernel,
Peter Zijlstra, Thomas Gleixner, Arnd Bergmann, Pekka Enberg,
Julian Anastasov
In-Reply-To: <20110321221357.GF22625@verge.net.au>
On Tue, Mar 22, 2011 at 07:13:58AM +0900, Simon Horman wrote:
> On Mon, Mar 21, 2011 at 09:15:40PM +0100, Eric Dumazet wrote:
> > Le lundi 21 mars 2011 à 19:07 +0100, Eric Dumazet a écrit :
> > > Le lundi 21 mars 2011 à 18:39 +0100, Ingo Molnar a écrit :
> > > > here's the same but with kallsyms enabled.
> > > >
> > > > Thanks,
> > > >
> > > > Ingo
> > > >
> > > > [ 9.585627] initcall 0xffffffff81d5b806 returned 0 after 0 usecs
> > > > [ 9.588960] calling 0xffffffff81d5b9da @ 1
> > > > [ 9.592303] IPVS: Creating netns size=1272 id=0
> > > > [ 9.595646] IPVS: __ip_vs_control_init(): alloc_percpu.
> > > > [ 9.602298] IPVS: cannot register namespace.
> > > > [ 9.605627] IPVS: can't setup control
> > >
> > > It seems IPVS is busted in case of memory allocation error in
> > > __ip_vs_control_init()
> > >
> > > IPVS deinits its "struct netns_ipvs" space, but something (in IPVS) uses
> > > it after free.
> > >
> > > __ip_vs_init() seems to be called before ip_vs_init() completes
> > > correctly. We then keep in net->ipvs a pointer to some freed memory.
> > >
> > > Commit 14e405461e664b7 did some changes in this area
> > >
> > > Simon, any idea ?
> > >
> > >
> >
> > For the time being, we can avoid the false memory allocation error (and
> > leak)
>
> Sorry, that typo is my work.
With your patch applied I now see the following
ffff880003bbf1a0 corresponds to &ipvs->app_key in __ip_vs_app_init().
I'll continue looking into this.
[ 12.610000] IPVS: Creating netns size=2456 id=0
[ 12.630000] IPVS: Registered protocols (TCP, UDP, SCTP, AH, ESP)
[ 12.640000] BUG: key ffff880003bbf1a0 not in .data!
[ 12.640000] ------------[ cut here ]------------
[ 12.640000] WARNING: at kernel/lockdep.c:2701
lockdep_init_map+0x37b/0x570()
[ 12.640000] Hardware name: Bochs
[ 12.640000] Pid: 1, comm: swapper Tainted: G W
2.6.38-kexec-06330-g69b7efe-dirty #122
[ 12.650000] Call Trace:
[ 12.650000] [<ffffffff8102e685>] warn_slowpath_common+0x75/0xb0
[ 12.650000] [<ffffffff8102e6d5>] warn_slowpath_null+0x15/0x20
[ 12.650000] [<ffffffff8105967b>] lockdep_init_map+0x37b/0x570
[ 12.650000] [<ffffffff8105829d>] ? trace_hardirqs_on+0xd/0x10
[ 12.650000] [<ffffffff81055ad8>] debug_mutex_init+0x38/0x50
[ 12.650000] [<ffffffff8104bc4c>] __mutex_init+0x5c/0x70
[ 12.650000] [<ffffffff81685ee7>] __ip_vs_app_init+0x64/0x86
[ 12.660000] [<ffffffff81685a3b>] ? ip_vs_init+0x0/0xff
[ 12.660000] [<ffffffff811b1c33>] T.620+0x43/0x170
[ 12.660000] [<ffffffff811b1e9a>] ? register_pernet_subsys+0x1a/0x40
[ 12.660000] [<ffffffff81685a3b>] ? ip_vs_init+0x0/0xff
[ 12.660000] [<ffffffff81685a3b>] ? ip_vs_init+0x0/0xff
[ 12.660000] [<ffffffff811b1db7>] register_pernet_operations+0x57/0xb0
[ 12.660000] [<ffffffff81685a3b>] ? ip_vs_init+0x0/0xff
[ 12.670000] [<ffffffff811b1ea9>] register_pernet_subsys+0x29/0x40
[ 12.670000] [<ffffffff81685f19>] ip_vs_app_init+0x10/0x12
[ 12.670000] [<ffffffff81685a87>] ip_vs_init+0x4c/0xff
[ 12.670000] [<ffffffff8166562c>] do_one_initcall+0x7a/0x12e
[ 12.670000] [<ffffffff8166583e>] kernel_init+0x13e/0x1c2
[ 12.670000] [<ffffffff8128c134>] kernel_thread_helper+0x4/0x10
[ 12.670000] [<ffffffff8128ad40>] ? restore_args+0x0/0x30
[ 12.680000] [<ffffffff81665700>] ? kernel_init+0x0/0x1c2
[ 12.680000] [<ffffffff8128c130>] ? kernel_thread_helper+0x0/0x10
[ 12.680000] ---[ end trace 4eaa2a86a8e2da23 ]---
^ permalink raw reply
* Re: [PATCH][v3] dev : fix mtu check when TSO is enabled
From: Eric W. Biederman @ 2011-03-21 22:58 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Daniel Lezcano, David Miller, eric.dumazet, kaber, nightnord,
netdev
In-Reply-To: <20110316094535.5ac6acd8@nehalam>
Stephen Hemminger <shemminger@vyatta.com> writes:
> On Wed, 16 Mar 2011 17:19:14 +0100
> Daniel Lezcano <daniel.lezcano@free.fr> wrote:
>
>> On 03/16/2011 04:35 PM, Stephen Hemminger wrote:
>> > On Wed, 16 Mar 2011 14:56:09 +0100
>> > Daniel Lezcano<daniel.lezcano@free.fr> wrote:
>> >
>> >> On 03/15/2011 07:17 PM, Stephen Hemminger wrote:
>> >>> On Tue, 15 Mar 2011 14:57:40 +0100
>> >>> Daniel Lezcano<daniel.lezcano@free.fr> wrote:
>> >>>
>> >>>> On 03/15/2011 12:59 AM, David Miller wrote:
>> >>>>> From: Daniel Lezcano<daniel.lezcano@free.fr>
>> >>>>> Date: Mon, 14 Mar 2011 21:39:50 +0100
>> >>>>>
>> >>>>>> + len = dev->mtu + dev->hard_header_len + VLAN_HLEN;
>> >>>>>> + if (skb->len< len)
>> >>>>>> + return true;
>> >>>>> This is not a correct translation of the original test:
>> >>>>>
>> >>>>>> - (skb->len> (dev->mtu + dev->hard_header_len + VLAN_HLEN)))) {
>> >>>>> You need to use "<=" in your version, which currently rejects all
>> >>>>> full sized frames. :-)
>> >>>> Right, thanks.
>> >>>>
>> >>>>>> +
>> >>>>>> + /* if TSO is enabled, we don't care about the length as the packet
>> >>>>>> + * could be forwarded without being segmented before
>> >>>>>> + */
>> >>>>>> + if (skb->dev&& skb->dev->features& NETIF_F_TSO)
>> >>>>>> + return true;
>> >>>>> I am trying to understand why you aren't simply checking also if this
>> >>>>> is a segmented frame? Perhaps skb_is_gso()&& device has NETIF_F_TSO
>> >>>>> set?
>> >>>> Maybe I am misunderstanding but the packet was forwarded by another device.
>> >>>> In our case from macvlan:
>> >>>>
>> >>>> macvlan_start_xmit
>> >>>> macvlan_queue_xmit
>> >>>> dest->forward
>> >>>> dev_skb_forward
>> >>>>
>> >>>> When we reached dev_skb_forward, that means we passed through
>> >>>> dev_hard_start_xmit where the packet was already segmented so we should
>> >>>> exit at the first test (skb->len< len). I don't see the point of adding
>> >>>> the skb_is_gso.
>> >>>> But maybe I am missing something, can you explain ?
>> >>> The macvlan device only has one downstream device (slave).
>> >>> If kernel is working properly, macvlan device should have a subset
>> >>> of the features of the underlying device
>> >> Right, dev->features = lowerdev->features& MACVLAN_FEATURES
>> >>
>> >>> and macvlan device should
>> >>> have same MTU as underlying device.
>> >> Right,
>> >>
>> >> ...
>> >>
>> >> if (!tb[IFLA_MTU])
>> >> dev->mtu = lowerdev->mtu;
>> >>
>> >> ...
>> >>> If the feature/MTU flags
>> >>> were correct, then the path calling macvlan should be respecting
>> >>> the MTU.
>> >> But if the TSO is enabled on the macvlan (inherited from eg e1000), the
>> >> packet won't be fragmented to the mtu size no ?
>> > That is the responsiblity of the hardware that receives the packet.
>> > Macvlan should be passing it through to the lowerdev and since the hardware
>> > supports TSO, it will fragment it.
>>
>> Ok, but in the case the macvlan is in bridge mode, the dev_skb_forward
>> function will forward the packet (which is not fragmented) to to another
>> macvlan port without going through the hardware driver. In this
>> function, the packet length is checked against the mtu size and of
>> course the packet is dropped in case the lower device support the TSO
>> (if the packet is larger than the mtu size). Dave suggested to check
>> skb_is_gso and against the TSO feature of the macvlan but I don't
>> understand why we should check skb_is_gso too.
>>
>> if (skb_is_gso(skb)&& (skb->dev&& skb->dev->features& NETIF_F_TSO))
>> return true;
>>
>>
>
> Then it is up to macvlan to do the same thing as bridge code.
>
> static inline unsigned packet_length(const struct sk_buff *skb)
> {
> return skb->len - (skb->protocol == htons(ETH_P_8021Q) ? VLAN_HLEN : 0);
> }
Which is incorrect in this context. skb->len at this point in the code
includes the ethernet header, as we are down below dev_queue_xmit.
The test really does need to be dev->mtu + dev->hard_header_len.
As for conditionally include the VLAN_HLEN that is likely doable but I
think if we are being pedantic that case needs to deal with accelerated
vlan headers.
> int br_dev_queue_push_xmit(struct sk_buff *skb)
> {
> /* ip_fragment doesn't copy the MAC header */
> if (nf_bridge_maybe_copy_header(skb) ||
> (packet_length(skb) > skb->dev->mtu && !skb_is_gso(skb))) {
> kfree_skb(skb);
> } else {
> skb_push(skb, ETH_HLEN);
> dev_queue_xmit(skb);
> }
e>
> return 0;
> }
> Ps: not sure adding macvlan bridge mode was a good idea, we already have
> a working bridge code. And there are too many missing pieces in the macvlan
> implementation of bridging
The macvlan is a trivial bridge that doesn't need to do learning as it
knows every mac address it can receive, so it doesn't need to implement
learning or stp. Which makes it simple stupid and and fast.
Strictly speaking the problems we are running into are the problems of
hardware acceleration and software devices, not properly providing the
same interfaces as the hardware. To not take a significant hit on
performance we do want hardware acceleration on the path to real
hardware from the transmitter.
To use the network bridge to cross network namespaces we would have to
add veth pairs and unless something has drastically changed we would
still need to emulate all of the hardware acceleration in so the
dev_forward_skb so that we don't provide a device to the bridge that
has lesser capabilities than the real hardware and downgrade the
capabilities of the entire bridge.
So I don't think there is much that would be gained by using bridges
instead of the macvlan driver.
Eric
^ permalink raw reply
* [PATCH] usbnet: fix memory leak in usbnet_disconnect()
From: DMITRIY GRUZMAN @ 2011-03-21 21:49 UTC (permalink / raw)
To: netdev; +Cc: Fulei TIAN, Chang Junxiao
usb_probe() allocates memory for transfer buffer and urb and this
memory was not properly released in usbnet_disconnect(). The issue
was found and the fix was recommended by Fu-Lei Tian and Jun-Xiao
Chang.
Signed-off-by: Dmitriy Gruzman <xmb836@motorola.com>
---
drivers/net/usb/usbnet.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index c04d49e..67a5728 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -210,6 +210,7 @@ static int init_status (struct usbnet *dev, struct
usb_interface *intf)
} else {
usb_fill_int_urb(dev->interrupt, dev->udev, pipe,
buf, maxp, intr_complete, dev, period);
+ dev->interrupt->transfer_flags |= URB_FREE_BUFFER;
dev_dbg(&intf->dev,
"status ep%din, %d bytes period %d\n",
usb_pipeendpoint(pipe), maxp, period);
@@ -1237,6 +1238,7 @@ void usbnet_disconnect (struct usb_interface *intf)
if (dev->driver_info->unbind)
dev->driver_info->unbind (dev, intf);
+ usb_free_urb(dev->interrupt);
free_netdev(net);
usb_put_dev (xdev);
}
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] Add useful per-connection TCP stats for diagnosis purpose.
From: Ben Greear @ 2011-03-21 22:19 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Jerry Chu, Eric Dumazet, netdev
In-Reply-To: <20110321141844.25e96184@s6510>
On 03/21/2011 02:18 PM, Stephen Hemminger wrote:
> In case it isn't clear. /proc/net/tcp is a legacy interface and any
> changes to it are certain to be rejected. netlink stats are an extensible
> interface and likely to be accepted.
Might be nice to have this available via
getsockopt(s, 6, /*SOL_TCP,*/ TCP_INFO, (void*)&info, &argsz)
as well.
Thanks,
Ben
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [slab poison overwritten] Re: [GIT] Networking
From: Simon Horman @ 2011-03-21 22:13 UTC (permalink / raw)
To: Eric Dumazet
Cc: Ingo Molnar, David Miller, torvalds, akpm, netdev, linux-kernel,
Peter Zijlstra, Thomas Gleixner, Arnd Bergmann, Pekka Enberg,
Julian Anastasov
In-Reply-To: <1300738540.2837.5.camel@edumazet-laptop>
On Mon, Mar 21, 2011 at 09:15:40PM +0100, Eric Dumazet wrote:
> Le lundi 21 mars 2011 à 19:07 +0100, Eric Dumazet a écrit :
> > Le lundi 21 mars 2011 à 18:39 +0100, Ingo Molnar a écrit :
> > > here's the same but with kallsyms enabled.
> > >
> > > Thanks,
> > >
> > > Ingo
> > >
> > > [ 9.585627] initcall 0xffffffff81d5b806 returned 0 after 0 usecs
> > > [ 9.588960] calling 0xffffffff81d5b9da @ 1
> > > [ 9.592303] IPVS: Creating netns size=1272 id=0
> > > [ 9.595646] IPVS: __ip_vs_control_init(): alloc_percpu.
> > > [ 9.602298] IPVS: cannot register namespace.
> > > [ 9.605627] IPVS: can't setup control
> >
> > It seems IPVS is busted in case of memory allocation error in
> > __ip_vs_control_init()
> >
> > IPVS deinits its "struct netns_ipvs" space, but something (in IPVS) uses
> > it after free.
> >
> > __ip_vs_init() seems to be called before ip_vs_init() completes
> > correctly. We then keep in net->ipvs a pointer to some freed memory.
> >
> > Commit 14e405461e664b7 did some changes in this area
> >
> > Simon, any idea ?
> >
> >
>
> For the time being, we can avoid the false memory allocation error (and
> leak)
Sorry, that typo is my work.
> Thanks
>
> [PATCH] ipvs: fix a typo in __ip_vs_control_init()
>
> Reported-by: Ingo Molnar <mingo@elte.hu>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: Simon Horman <horms@verge.net.au>
> Cc: Julian Anastasov <ja@ssi.bg>
Acked-by: Simon Horman <horms@verge.net.au>
> ---
> net/netfilter/ipvs/ip_vs_ctl.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
> index b799cea..33733c8 100644
> --- a/net/netfilter/ipvs/ip_vs_ctl.c
> +++ b/net/netfilter/ipvs/ip_vs_ctl.c
> @@ -3605,7 +3605,7 @@ int __net_init __ip_vs_control_init(struct net *net)
>
> /* procfs stats */
> ipvs->tot_stats.cpustats = alloc_percpu(struct ip_vs_cpu_stats);
> - if (ipvs->tot_stats.cpustats) {
> + if (!ipvs->tot_stats.cpustats) {
> pr_err("%s(): alloc_percpu.\n", __func__);
> return -ENOMEM;
> }
>
>
^ permalink raw reply
* Re: [PATCH] net: Handle gso packets in dev_forward_skb
From: Eric W. Biederman @ 2011-03-21 22:00 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, netdev, Ben Greear, Arnd Bergmann, Patrick McHardy
In-Reply-To: <1300743744.2837.7.camel@edumazet-laptop>
Eric Dumazet <eric.dumazet@gmail.com> writes:
> Hmm, did you follow http://patchwork.ozlabs.org/patch/86815/
> discussion ?
No. It seems I missed it, but I do have the same problem, and
essentially the same fix.
Eric
^ permalink raw reply
* Re: [PATCH] net: Handle gso packets in dev_forward_skb
From: Eric Dumazet @ 2011-03-21 21:42 UTC (permalink / raw)
To: Eric W. Biederman
Cc: David Miller, netdev, Ben Greear, Arnd Bergmann, Patrick McHardy
In-Reply-To: <m1wrjsi2tf.fsf@fess.ebiederm.org>
Le lundi 21 mars 2011 à 14:25 -0700, Eric W. Biederman a écrit :
> Today when gso packets reach dev_forward_skb through the macvlan driver
> we drop them on the floor because they exceed the device mtu. Ouch!
>
> I don't undersand the subtelties of gso but I think it is sufficient to
> simply relax the checks and let gso packets through without an mtu
> check, and it works in my test case.
>
> If needed we can split the gso packets into multiple packets here but
> that just seems like a wast of memory and time.
>
> Signed-off-by: Eric W. Biederman <ebiederm@aristanetworks.com>
> ---
> net/core/dev.c | 16 ++++++++++------
> 1 files changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 0b88eba..2e26606 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -1527,17 +1527,21 @@ int dev_forward_skb(struct net_device *dev, struct sk_buff *skb)
> skb_orphan(skb);
> nf_reset(skb);
>
> - if (unlikely(!(dev->flags & IFF_UP) ||
> - (skb->len > (dev->mtu + dev->hard_header_len + VLAN_HLEN)))) {
> - atomic_long_inc(&dev->rx_dropped);
> - kfree_skb(skb);
> - return NET_RX_DROP;
> - }
> + if (unlikely(!(dev->flags & IFF_UP)))
> + goto kfree_skb;
> + /* Don't check mtu on gso packets... */
> + if (unlikely(!skb_is_gso(skb) &&
> + (skb->len > (dev->mtu + dev->hard_header_len + VLAN_HLEN))))
> + goto kfree_skb;
> skb_set_dev(skb, dev);
> skb->tstamp.tv64 = 0;
> skb->pkt_type = PACKET_HOST;
> skb->protocol = eth_type_trans(skb, dev);
> return netif_rx(skb);
> +kfree_skb:
> + atomic_long_inc(&dev->rx_dropped);
> + kfree_skb(skb);
> + return NET_RX_DROP;
> }
> EXPORT_SYMBOL_GPL(dev_forward_skb);
>
Hmm, did you follow http://patchwork.ozlabs.org/patch/86815/
discussion ?
^ permalink raw reply
* [PATCH] veth: Fix the byte counters
From: Eric W. Biederman @ 2011-03-21 21:40 UTC (permalink / raw)
To: David Miller
Cc: netdev, Michał Mirosław, Eric Dumazet, Arnd Bergmann,
Ben Greear, Patrick McHardy, Daniel Lezcano, Pavel Emelyanov
Commit 44540960 "veth: move loopback logic to common location" introduced
a bug in the packet counters. I don't understand why that happened as it
is not explained in the comments and the mut check in dev_forward_skb
retains the assumption that skb->len is the total length of the packet.
I just measured this emperically by setting up a veth pair between two
noop network namespaces setting and attempting a telnet connection between
the two. I saw three packets in each direction and the byte counters were
exactly 14*3 = 42 bytes high in each direction. I got the actual
packet lengths with tcpdump.
So remove the extra ETH_HLEN from the veth byte count totals.
Signed-off-by: Eric W. Biederman <ebiederm@aristanetworks.com>
---
drivers/net/veth.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/veth.c b/drivers/net/veth.c
index 105d7f0..2de9b90 100644
--- a/drivers/net/veth.c
+++ b/drivers/net/veth.c
@@ -171,7 +171,7 @@ static netdev_tx_t veth_xmit(struct sk_buff *skb, struct net_device *dev)
if (skb->ip_summed == CHECKSUM_NONE)
skb->ip_summed = rcv_priv->ip_summed;
- length = skb->len + ETH_HLEN;
+ length = skb->len;
if (dev_forward_skb(rcv, skb) != NET_RX_SUCCESS)
goto rx_drop;
--
1.7.4
^ permalink raw reply related
* [PATCH] vlan: Fix duplicate delivery of vlan 0 packets to ETH_P_ALL packet sockets
From: Eric W. Biederman @ 2011-03-21 21:35 UTC (permalink / raw)
To: David Miller
Cc: netdev, Michał Mirosław, Ben Hutchings, Jesse Gross,
Eric Dumazet, John Fastabend
For vlan data coming in from nics without vlan hardware accelleration we
get two copies of vlan packets with vlan id 0 on pf_packet sockets, causing
userspace to break. This is caused by delivering the same packet to the same
networking device more than once.
The cleanest and simplist fix I can find is to make the vlan accellerated path
the common path for vlan tagged packets. Moving the classification of vlan
tagged packets sooner and removes the need for vlan 0 packets to be double
delivered. This has a small impact on the fast path.
The penalty on the fast path for the non-vlan tagged case should be a single
forward branch that is always predicted as not taken. With some clean up
to the routines for vlan accelleration and non-vlan accelleration we should
be able to even remove that branch if it is a problem.
Once the classification is moved sooner the traditional vlan reception path
can be removed entirely. Reducing duplicate maintenance for the vlan code.
Receiving non vlan accellerated packets into vlan_accel_do_receive only requires
adding the special case for hiding the vlan header from pf_packet sockets on
vlan headers.
While moving the code to hide the packet sockets I have fixed two bugs. I moved
the rx_error case inside the proper stats collection bracket, and I have reduced
the received packet size by the number of bytes we are hiding.
Signed-off-by: Eric W. Biederman <ebiederm@aristanetworks.com>
---
include/linux/if_vlan.h | 5 ++
net/8021q/vlan.c | 8 --
net/8021q/vlan.h | 2 -
net/8021q/vlan_core.c | 49 +++++++++++++-
net/8021q/vlan_dev.c | 173 -----------------------------------------------
net/core/dev.c | 9 +++
6 files changed, 62 insertions(+), 184 deletions(-)
diff --git a/include/linux/if_vlan.h b/include/linux/if_vlan.h
index 635e1fa..7259fca 100644
--- a/include/linux/if_vlan.h
+++ b/include/linux/if_vlan.h
@@ -133,6 +133,7 @@ extern u16 vlan_dev_vlan_id(const struct net_device *dev);
extern int __vlan_hwaccel_rx(struct sk_buff *skb, struct vlan_group *grp,
u16 vlan_tci, int polling);
extern bool vlan_hwaccel_do_receive(struct sk_buff **skb);
+extern void emulate_vlan_hwaccel(struct sk_buff *skb);
extern gro_result_t
vlan_gro_receive(struct napi_struct *napi, struct vlan_group *grp,
unsigned int vlan_tci, struct sk_buff *skb);
@@ -173,6 +174,10 @@ static inline bool vlan_hwaccel_do_receive(struct sk_buff **skb)
return false;
}
+static void emulate_vlan_hwaccel(struct sk_buff *skb)
+{
+}
+
static inline gro_result_t
vlan_gro_receive(struct napi_struct *napi, struct vlan_group *grp,
unsigned int vlan_tci, struct sk_buff *skb)
diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
index 7850412..59f0a9d 100644
--- a/net/8021q/vlan.c
+++ b/net/8021q/vlan.c
@@ -49,11 +49,6 @@ const char vlan_version[] = DRV_VERSION;
static const char vlan_copyright[] = "Ben Greear <greearb@candelatech.com>";
static const char vlan_buggyright[] = "David S. Miller <davem@redhat.com>";
-static struct packet_type vlan_packet_type __read_mostly = {
- .type = cpu_to_be16(ETH_P_8021Q),
- .func = vlan_skb_recv, /* VLAN receive method */
-};
-
/* End of global variables definitions. */
static void vlan_group_free(struct vlan_group *grp)
@@ -688,7 +683,6 @@ static int __init vlan_proto_init(void)
if (err < 0)
goto err4;
- dev_add_pack(&vlan_packet_type);
vlan_ioctl_set(vlan_ioctl_handler);
return 0;
@@ -709,8 +703,6 @@ static void __exit vlan_cleanup_module(void)
unregister_netdevice_notifier(&vlan_notifier_block);
- dev_remove_pack(&vlan_packet_type);
-
unregister_pernet_subsys(&vlan_net_ops);
rcu_barrier(); /* Wait for completion of call_rcu()'s */
diff --git a/net/8021q/vlan.h b/net/8021q/vlan.h
index 5687c9b..c3408de 100644
--- a/net/8021q/vlan.h
+++ b/net/8021q/vlan.h
@@ -75,8 +75,6 @@ static inline struct vlan_dev_info *vlan_dev_info(const struct net_device *dev)
}
/* found in vlan_dev.c */
-int vlan_skb_recv(struct sk_buff *skb, struct net_device *dev,
- struct packet_type *ptype, struct net_device *orig_dev);
void vlan_dev_set_ingress_priority(const struct net_device *dev,
u32 skb_prio, u16 vlan_prio);
int vlan_dev_set_egress_priority(const struct net_device *dev,
diff --git a/net/8021q/vlan_core.c b/net/8021q/vlan_core.c
index ce8e3ab..a0849b9 100644
--- a/net/8021q/vlan_core.c
+++ b/net/8021q/vlan_core.c
@@ -4,6 +4,35 @@
#include <linux/netpoll.h>
#include "vlan.h"
+void emulate_vlan_hwaccel(struct sk_buff *skb)
+{
+ struct vlan_hdr *vhdr = (struct vlan_hdr *)skb->data;
+ __be16 proto;
+
+ if (!pskb_may_pull(skb, VLAN_HLEN))
+ return;
+
+ __vlan_hwaccel_put_tag(skb, vhdr->h_vlan_TCI);
+ skb_pull_rcsum(skb, VLAN_HLEN);
+
+ proto = vhdr->h_vlan_encapsulated_proto;
+ if (ntohs(proto) >= 1536)
+ skb->protocol = proto;
+ /*
+ * This is a magic hack to spot IPX packets. Older Novell breaks
+ * the protocol design and runs IPX over 802.3 without an 802.2 LLC
+ * layer. We look for FFFF which isn't a used 802.2 SSAP/DSAP. This
+ * won't work for fault tolerant netware but does for the rest.
+ */
+ else if (skb->len >= 2 && *(unsigned short *)(skb->data) == 0xFFFF)
+ skb->protocol = htons(ETH_P_802_3);
+ /*
+ * Real 802.2 LLC
+ */
+ else
+ skb->protocol = htons(ETH_P_802_2);
+}
+
bool vlan_hwaccel_do_receive(struct sk_buff **skbp)
{
struct sk_buff *skb = *skbp;
@@ -47,9 +76,27 @@ bool vlan_hwaccel_do_receive(struct sk_buff **skbp)
skb->pkt_type = PACKET_HOST;
break;
}
+
+ /* Hide the vlan header if it is present but we don't want to see it.
+ */
+ if ((skb->mac_len == VLAN_ETH_HLEN) &&
+ (vlan_dev_info(vlan_dev)->flags & VLAN_FLAG_REORDER_HDR)) {
+ if (skb_cow(skb, skb_headroom(skb)) < 0)
+ skb = NULL;
+ if (skb) {
+ /* Move up the mac addresses to hide the vlan header */
+ memmove(skb->data - ETH_HLEN,
+ skb->data - VLAN_ETH_HLEN, 12);
+ skb->mac_header += VLAN_HLEN;
+ rx_stats->rx_bytes -= VLAN_HLEN;
+ }
+ else
+ rx_stats->rx_errors++;
+ }
+
u64_stats_update_end(&rx_stats->syncp);
- return true;
+ return skb != NULL;
}
struct net_device *vlan_dev_real_dev(const struct net_device *dev)
diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
index ae610f0..f37b1d5 100644
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -65,179 +65,6 @@ static int vlan_dev_rebuild_header(struct sk_buff *skb)
return 0;
}
-static inline struct sk_buff *vlan_check_reorder_header(struct sk_buff *skb)
-{
- if (vlan_dev_info(skb->dev)->flags & VLAN_FLAG_REORDER_HDR) {
- if (skb_cow(skb, skb_headroom(skb)) < 0)
- skb = NULL;
- if (skb) {
- /* Lifted from Gleb's VLAN code... */
- memmove(skb->data - ETH_HLEN,
- skb->data - VLAN_ETH_HLEN, 12);
- skb->mac_header += VLAN_HLEN;
- }
- }
-
- return skb;
-}
-
-static inline void vlan_set_encap_proto(struct sk_buff *skb,
- struct vlan_hdr *vhdr)
-{
- __be16 proto;
- unsigned char *rawp;
-
- /*
- * Was a VLAN packet, grab the encapsulated protocol, which the layer
- * three protocols care about.
- */
-
- proto = vhdr->h_vlan_encapsulated_proto;
- if (ntohs(proto) >= 1536) {
- skb->protocol = proto;
- return;
- }
-
- rawp = skb->data;
- if (*(unsigned short *)rawp == 0xFFFF)
- /*
- * This is a magic hack to spot IPX packets. Older Novell
- * breaks the protocol design and runs IPX over 802.3 without
- * an 802.2 LLC layer. We look for FFFF which isn't a used
- * 802.2 SSAP/DSAP. This won't work for fault tolerant netware
- * but does for the rest.
- */
- skb->protocol = htons(ETH_P_802_3);
- else
- /*
- * Real 802.2 LLC
- */
- skb->protocol = htons(ETH_P_802_2);
-}
-
-/*
- * Determine the packet's protocol ID. The rule here is that we
- * assume 802.3 if the type field is short enough to be a length.
- * This is normal practice and works for any 'now in use' protocol.
- *
- * Also, at this point we assume that we ARE dealing exclusively with
- * VLAN packets, or packets that should be made into VLAN packets based
- * on a default VLAN ID.
- *
- * NOTE: Should be similar to ethernet/eth.c.
- *
- * SANITY NOTE: This method is called when a packet is moving up the stack
- * towards userland. To get here, it would have already passed
- * through the ethernet/eth.c eth_type_trans() method.
- * SANITY NOTE 2: We are referencing to the VLAN_HDR frields, which MAY be
- * stored UNALIGNED in the memory. RISC systems don't like
- * such cases very much...
- * SANITY NOTE 2a: According to Dave Miller & Alexey, it will always be
- * aligned, so there doesn't need to be any of the unaligned
- * stuff. It has been commented out now... --Ben
- *
- */
-int vlan_skb_recv(struct sk_buff *skb, struct net_device *dev,
- struct packet_type *ptype, struct net_device *orig_dev)
-{
- struct vlan_hdr *vhdr;
- struct vlan_pcpu_stats *rx_stats;
- struct net_device *vlan_dev;
- u16 vlan_id;
- u16 vlan_tci;
-
- skb = skb_share_check(skb, GFP_ATOMIC);
- if (skb == NULL)
- goto err_free;
-
- if (unlikely(!pskb_may_pull(skb, VLAN_HLEN)))
- goto err_free;
-
- vhdr = (struct vlan_hdr *)skb->data;
- vlan_tci = ntohs(vhdr->h_vlan_TCI);
- vlan_id = vlan_tci & VLAN_VID_MASK;
-
- rcu_read_lock();
- vlan_dev = vlan_find_dev(dev, vlan_id);
-
- /* If the VLAN device is defined, we use it.
- * If not, and the VID is 0, it is a 802.1p packet (not
- * really a VLAN), so we will just netif_rx it later to the
- * original interface, but with the skb->proto set to the
- * wrapped proto: we do nothing here.
- */
-
- if (!vlan_dev) {
- if (vlan_id) {
- pr_debug("%s: ERROR: No net_device for VID: %u on dev: %s\n",
- __func__, vlan_id, dev->name);
- goto err_unlock;
- }
- rx_stats = NULL;
- } else {
- skb->dev = vlan_dev;
-
- rx_stats = this_cpu_ptr(vlan_dev_info(skb->dev)->vlan_pcpu_stats);
-
- u64_stats_update_begin(&rx_stats->syncp);
- rx_stats->rx_packets++;
- rx_stats->rx_bytes += skb->len;
-
- skb->priority = vlan_get_ingress_priority(skb->dev, vlan_tci);
-
- pr_debug("%s: priority: %u for TCI: %hu\n",
- __func__, skb->priority, vlan_tci);
-
- switch (skb->pkt_type) {
- case PACKET_BROADCAST:
- /* Yeah, stats collect these together.. */
- /* stats->broadcast ++; // no such counter :-( */
- break;
-
- case PACKET_MULTICAST:
- rx_stats->rx_multicast++;
- break;
-
- case PACKET_OTHERHOST:
- /* Our lower layer thinks this is not local, let's make
- * sure.
- * This allows the VLAN to have a different MAC than the
- * underlying device, and still route correctly.
- */
- if (!compare_ether_addr(eth_hdr(skb)->h_dest,
- skb->dev->dev_addr))
- skb->pkt_type = PACKET_HOST;
- break;
- default:
- break;
- }
- u64_stats_update_end(&rx_stats->syncp);
- }
-
- skb_pull_rcsum(skb, VLAN_HLEN);
- vlan_set_encap_proto(skb, vhdr);
-
- if (vlan_dev) {
- skb = vlan_check_reorder_header(skb);
- if (!skb) {
- rx_stats->rx_errors++;
- goto err_unlock;
- }
- }
-
- netif_rx(skb);
-
- rcu_read_unlock();
- return NET_RX_SUCCESS;
-
-err_unlock:
- rcu_read_unlock();
-err_free:
- atomic_long_inc(&dev->rx_dropped);
- kfree_skb(skb);
- return NET_RX_DROP;
-}
-
static inline u16
vlan_dev_get_egress_qos_mask(struct net_device *dev, struct sk_buff *skb)
{
diff --git a/net/core/dev.c b/net/core/dev.c
index 2e26606..53d17f1 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3152,6 +3152,15 @@ static int __netif_receive_skb(struct sk_buff *skb)
skb->skb_iif = skb->dev->ifindex;
orig_dev = skb->dev;
+ /* If a vlan header is present pretend to be hardware accelerated
+ * to remove special cases and to prevent duplicate delivery to
+ * ETH_P_ALL sockets in the case vlan id == 0, where the vlan
+ * header is only used to set the packets priority.
+ */
+ if (unlikely(skb->protocol == htons(ETH_P_8021Q) &&
+ !vlan_tx_tag_present(skb)))
+ emulate_vlan_hwaccel(skb);
+
skb_reset_network_header(skb);
skb_reset_transport_header(skb);
skb->mac_len = skb->network_header - skb->mac_header;
--
1.7.4
^ permalink raw reply related
* [PATCH] net: Handle gso packets in dev_forward_skb
From: Eric W. Biederman @ 2011-03-21 21:25 UTC (permalink / raw)
To: David Miller
Cc: netdev, Ben Greear, Eric Dumazet, Arnd Bergmann, Patrick McHardy
Today when gso packets reach dev_forward_skb through the macvlan driver
we drop them on the floor because they exceed the device mtu. Ouch!
I don't undersand the subtelties of gso but I think it is sufficient to
simply relax the checks and let gso packets through without an mtu
check, and it works in my test case.
If needed we can split the gso packets into multiple packets here but
that just seems like a wast of memory and time.
Signed-off-by: Eric W. Biederman <ebiederm@aristanetworks.com>
---
net/core/dev.c | 16 ++++++++++------
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 0b88eba..2e26606 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1527,17 +1527,21 @@ int dev_forward_skb(struct net_device *dev, struct sk_buff *skb)
skb_orphan(skb);
nf_reset(skb);
- if (unlikely(!(dev->flags & IFF_UP) ||
- (skb->len > (dev->mtu + dev->hard_header_len + VLAN_HLEN)))) {
- atomic_long_inc(&dev->rx_dropped);
- kfree_skb(skb);
- return NET_RX_DROP;
- }
+ if (unlikely(!(dev->flags & IFF_UP)))
+ goto kfree_skb;
+ /* Don't check mtu on gso packets... */
+ if (unlikely(!skb_is_gso(skb) &&
+ (skb->len > (dev->mtu + dev->hard_header_len + VLAN_HLEN))))
+ goto kfree_skb;
skb_set_dev(skb, dev);
skb->tstamp.tv64 = 0;
skb->pkt_type = PACKET_HOST;
skb->protocol = eth_type_trans(skb, dev);
return netif_rx(skb);
+kfree_skb:
+ atomic_long_inc(&dev->rx_dropped);
+ kfree_skb(skb);
+ return NET_RX_DROP;
}
EXPORT_SYMBOL_GPL(dev_forward_skb);
--
1.7.4
^ permalink raw reply related
* [PATCH] net ipv6: Fix duplicate /proc/sys/net/ipv6/neigh directory entries.
From: Eric W. Biederman @ 2011-03-21 21:20 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Andrew Morton, sunkan
When I was fixing issues with unregisgtering tables under /proc/sys/net/ipv6/neigh
by adding a mount point it appears I missed a critical ordering issue, in the
ipv6 initialization. I had not realized that ipv6_sysctl_register is called
at the very end of the ipv6 initialization and in particular after we call
neigh_sysctl_register from ndisc_init.
"neigh" needs to be initialized in ipv6_static_sysctl_register which is
the first ipv6 table to initialized, and definitely before ndisc_init.
This removes the weirdness of duplicate tables while still providing a
"neigh" mount point which prevents races in sysctl unregistering.
This was initially reported at https://bugzilla.kernel.org/show_bug.cgi?id=31232
Reported-by: sunkan@zappa.cx
Signed-off-by: Eric W. Biederman <ebiederm@aristanetworks.com>
---
net/ipv6/sysctl_net_ipv6.c | 18 +++++++++++-------
1 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/net/ipv6/sysctl_net_ipv6.c b/net/ipv6/sysctl_net_ipv6.c
index 7cb65ef..6dcf5e7 100644
--- a/net/ipv6/sysctl_net_ipv6.c
+++ b/net/ipv6/sysctl_net_ipv6.c
@@ -17,6 +17,16 @@
static struct ctl_table empty[1];
+static ctl_table ipv6_static_skeleton[] = {
+ {
+ .procname = "neigh",
+ .maxlen = 0,
+ .mode = 0555,
+ .child = empty,
+ },
+ { }
+};
+
static ctl_table ipv6_table_template[] = {
{
.procname = "route",
@@ -37,12 +47,6 @@ static ctl_table ipv6_table_template[] = {
.mode = 0644,
.proc_handler = proc_dointvec
},
- {
- .procname = "neigh",
- .maxlen = 0,
- .mode = 0555,
- .child = empty,
- },
{ }
};
@@ -160,7 +164,7 @@ static struct ctl_table_header *ip6_base;
int ipv6_static_sysctl_register(void)
{
- ip6_base = register_sysctl_paths(net_ipv6_ctl_path, empty);
+ ip6_base = register_sysctl_paths(net_ipv6_ctl_path, ipv6_static_skeleton);
if (ip6_base == NULL)
return -ENOMEM;
return 0;
--
1.7.4
^ permalink raw reply related
* Re: [PATCH] Add useful per-connection TCP stats for diagnosis purpose.
From: Stephen Hemminger @ 2011-03-21 21:18 UTC (permalink / raw)
To: Jerry Chu; +Cc: Eric Dumazet, netdev
In-Reply-To: <AANLkTikrJ7A-ygc9JnkvfBpRaKjL0fKeta+9ASLDr0rg@mail.gmail.com>
In case it isn't clear. /proc/net/tcp is a legacy interface and any
changes to it are certain to be rejected. netlink stats are an extensible
interface and likely to be accepted.
^ permalink raw reply
* [PATCH] macvlan: Fix use after free of struct macvlan_port.
From: Eric W. Biederman @ 2011-03-21 21:15 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Patrick McHardy, Ben Greear, Eric Dumazet
When the macvlan driver was extended to call unregisgter_netdevice_queue
in 23289a37e2b127dfc4de1313fba15bb4c9f0cd5b, a use after free of struct
macvlan_port was introduced. The code in dellink relied on unregister_netdevice
actually unregistering the net device so it would be safe to free macvlan_port.
Since unregister_netdevice_queue can just queue up the unregister instead of
performing the unregiser immediately we free the macvlan_port too soon and
then the code in macvlan_stop removes the macaddress for the set of macaddress
to listen for and uses memory that has already been freed.
To fix this add a reference count to track when it is safe to free the macvlan_port
and move the call of macvlan_port_destroy into macvlan_uninit which is guaranteed
to be called after the final macvlan_port_close.
Signed-off-by: Eric W. Biederman <ebiederm@aristanetworks.com>
---
drivers/net/macvlan.c | 18 ++++++++++++------
1 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index 5b37d3c..78e34e9 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -39,8 +39,11 @@ struct macvlan_port {
struct list_head vlans;
struct rcu_head rcu;
bool passthru;
+ int count;
};
+static void macvlan_port_destroy(struct net_device *dev);
+
#define macvlan_port_get_rcu(dev) \
((struct macvlan_port *) rcu_dereference(dev->rx_handler_data))
#define macvlan_port_get(dev) ((struct macvlan_port *) dev->rx_handler_data)
@@ -457,8 +460,13 @@ static int macvlan_init(struct net_device *dev)
static void macvlan_uninit(struct net_device *dev)
{
struct macvlan_dev *vlan = netdev_priv(dev);
+ struct macvlan_port *port = vlan->port;
free_percpu(vlan->pcpu_stats);
+
+ port->count -= 1;
+ if (!port->count)
+ macvlan_port_destroy(port->dev);
}
static struct rtnl_link_stats64 *macvlan_dev_get_stats64(struct net_device *dev,
@@ -691,12 +699,13 @@ int macvlan_common_newlink(struct net *src_net, struct net_device *dev,
vlan->mode = nla_get_u32(data[IFLA_MACVLAN_MODE]);
if (vlan->mode == MACVLAN_MODE_PASSTHRU) {
- if (!list_empty(&port->vlans))
+ if (port->count)
return -EINVAL;
port->passthru = true;
memcpy(dev->dev_addr, lowerdev->dev_addr, ETH_ALEN);
}
+ port->count += 1;
err = register_netdevice(dev);
if (err < 0)
goto destroy_port;
@@ -707,7 +716,8 @@ int macvlan_common_newlink(struct net *src_net, struct net_device *dev,
return 0;
destroy_port:
- if (list_empty(&port->vlans))
+ port->count -= 1;
+ if (!port->count)
macvlan_port_destroy(lowerdev);
return err;
@@ -725,13 +735,9 @@ static int macvlan_newlink(struct net *src_net, struct net_device *dev,
void macvlan_dellink(struct net_device *dev, struct list_head *head)
{
struct macvlan_dev *vlan = netdev_priv(dev);
- struct macvlan_port *port = vlan->port;
list_del(&vlan->list);
unregister_netdevice_queue(dev, head);
-
- if (list_empty(&port->vlans))
- macvlan_port_destroy(port->dev);
}
EXPORT_SYMBOL_GPL(macvlan_dellink);
--
1.7.4
^ permalink raw reply related
* [PATCH] fix incorrect spelling in drop monitor protocol
From: Neil Horman @ 2011-03-21 20:30 UTC (permalink / raw)
To: netdev; +Cc: davem, Neil Horman
It was pointed out to me recently that my spelling could be better :)
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
---
net/core/drop_monitor.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/core/drop_monitor.c b/net/core/drop_monitor.c
index 36e603c..706502f 100644
--- a/net/core/drop_monitor.c
+++ b/net/core/drop_monitor.c
@@ -350,7 +350,7 @@ static int __init init_net_drop_monitor(void)
struct per_cpu_dm_data *data;
int cpu, rc;
- printk(KERN_INFO "Initalizing network drop monitor service\n");
+ printk(KERN_INFO "Initializing network drop monitor service\n");
if (sizeof(void *) > 8) {
printk(KERN_ERR "Unable to store program counters on this arch, Drop monitor failed\n");
--
1.7.4
^ permalink raw reply related
* Re: [slab poison overwritten] Re: [GIT] Networking
From: Eric Dumazet @ 2011-03-21 20:15 UTC (permalink / raw)
To: Ingo Molnar
Cc: David Miller, torvalds, akpm, netdev, linux-kernel,
Peter Zijlstra, Thomas Gleixner, Arnd Bergmann, Pekka Enberg,
Simon Horman, Julian Anastasov
In-Reply-To: <1300730838.2884.578.camel@edumazet-laptop>
Le lundi 21 mars 2011 à 19:07 +0100, Eric Dumazet a écrit :
> Le lundi 21 mars 2011 à 18:39 +0100, Ingo Molnar a écrit :
> > here's the same but with kallsyms enabled.
> >
> > Thanks,
> >
> > Ingo
> >
> > [ 9.585627] initcall 0xffffffff81d5b806 returned 0 after 0 usecs
> > [ 9.588960] calling 0xffffffff81d5b9da @ 1
> > [ 9.592303] IPVS: Creating netns size=1272 id=0
> > [ 9.595646] IPVS: __ip_vs_control_init(): alloc_percpu.
> > [ 9.602298] IPVS: cannot register namespace.
> > [ 9.605627] IPVS: can't setup control
>
> It seems IPVS is busted in case of memory allocation error in
> __ip_vs_control_init()
>
> IPVS deinits its "struct netns_ipvs" space, but something (in IPVS) uses
> it after free.
>
> __ip_vs_init() seems to be called before ip_vs_init() completes
> correctly. We then keep in net->ipvs a pointer to some freed memory.
>
> Commit 14e405461e664b7 did some changes in this area
>
> Simon, any idea ?
>
>
For the time being, we can avoid the false memory allocation error (and
leak)
Thanks
[PATCH] ipvs: fix a typo in __ip_vs_control_init()
Reported-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Simon Horman <horms@verge.net.au>
Cc: Julian Anastasov <ja@ssi.bg>
---
net/netfilter/ipvs/ip_vs_ctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
index b799cea..33733c8 100644
--- a/net/netfilter/ipvs/ip_vs_ctl.c
+++ b/net/netfilter/ipvs/ip_vs_ctl.c
@@ -3605,7 +3605,7 @@ int __net_init __ip_vs_control_init(struct net *net)
/* procfs stats */
ipvs->tot_stats.cpustats = alloc_percpu(struct ip_vs_cpu_stats);
- if (ipvs->tot_stats.cpustats) {
+ if (!ipvs->tot_stats.cpustats) {
pr_err("%s(): alloc_percpu.\n", __func__);
return -ENOMEM;
}
^ permalink raw reply related
* Re: [GIT] Networking
From: Eric Dumazet @ 2011-03-21 20:10 UTC (permalink / raw)
To: Linus Torvalds; +Cc: David Miller, akpm, netdev, linux-kernel
In-Reply-To: <AANLkTinN3qszBjbJdkXb2TPBkAW0mXGC=Ri1zKL9gdNg@mail.gmail.com>
Le lundi 21 mars 2011 à 12:24 -0700, Linus Torvalds a écrit :
> On Sun, Mar 20, 2011 at 7:51 PM, David Miller <davem@davemloft.net> wrote:
> >
> > 1) The R8169 PHY fix from Eric Dumazet, which I see you've added to
> > your tree too. :-)
>
> Yeah, since my machine didn't have networking without it, and I could
> test it myself, I didn't wait to pull.
>
> That said, I'm delaying this pull request due to the known issues with
> it - let me know when you've updated it with the fix for the
> use-after-free fixes and the slab corruptor (the latter of which I
> haven't seen a patch for yet)
Seems to be related to one typo, but still we have to find the
corruption
diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
index b799cea..33733c8 100644
--- a/net/netfilter/ipvs/ip_vs_ctl.c
+++ b/net/netfilter/ipvs/ip_vs_ctl.c
@@ -3605,7 +3605,7 @@ int __net_init __ip_vs_control_init(struct net *net)
/* procfs stats */
ipvs->tot_stats.cpustats = alloc_percpu(struct ip_vs_cpu_stats);
- if (ipvs->tot_stats.cpustats) {
+ if (!ipvs->tot_stats.cpustats) {
pr_err("%s(): alloc_percpu.\n", __func__);
return -ENOMEM;
}
^ permalink raw reply related
* Re: [GIT] Networking
From: Linus Torvalds @ 2011-03-21 19:24 UTC (permalink / raw)
To: David Miller; +Cc: akpm, netdev, linux-kernel
In-Reply-To: <20110320.195156.226769634.davem@davemloft.net>
On Sun, Mar 20, 2011 at 7:51 PM, David Miller <davem@davemloft.net> wrote:
>
> 1) The R8169 PHY fix from Eric Dumazet, which I see you've added to
> your tree too. :-)
Yeah, since my machine didn't have networking without it, and I could
test it myself, I didn't wait to pull.
That said, I'm delaying this pull request due to the known issues with
it - let me know when you've updated it with the fix for the
use-after-free fixes and the slab corruptor (the latter of which I
haven't seen a patch for yet)
Linus
^ permalink raw reply
* Re: [slab poison overwritten] Re: [GIT] Networking
From: Eric Dumazet @ 2011-03-21 18:07 UTC (permalink / raw)
To: Ingo Molnar
Cc: David Miller, torvalds, akpm, netdev, linux-kernel,
Peter Zijlstra, Thomas Gleixner, Arnd Bergmann, Pekka Enberg,
Simon Horman
In-Reply-To: <20110321173941.GB3892@elte.hu>
Le lundi 21 mars 2011 à 18:39 +0100, Ingo Molnar a écrit :
> here's the same but with kallsyms enabled.
>
> Thanks,
>
> Ingo
>
> [ 9.585627] initcall 0xffffffff81d5b806 returned 0 after 0 usecs
> [ 9.588960] calling 0xffffffff81d5b9da @ 1
> [ 9.592303] IPVS: Creating netns size=1272 id=0
> [ 9.595646] IPVS: __ip_vs_control_init(): alloc_percpu.
> [ 9.602298] IPVS: cannot register namespace.
> [ 9.605627] IPVS: can't setup control
It seems IPVS is busted in case of memory allocation error in
__ip_vs_control_init()
IPVS deinits its "struct netns_ipvs" space, but something (in IPVS) uses
it after free.
__ip_vs_init() seems to be called before ip_vs_init() completes
correctly. We then keep in net->ipvs a pointer to some freed memory.
Commit 14e405461e664b7 did some changes in this area
Simon, any idea ?
^ permalink raw reply
* Re: [PATCH 2/2] virtio_net: remove send completion interrupts and avoid TX queue overrun through packet drop
From: Shirley Ma @ 2011-03-21 18:03 UTC (permalink / raw)
To: Herbert Xu; +Cc: mst, rusty, davem, kvm, netdev
In-Reply-To: <1300498915.3441.21.camel@localhost.localdomain>
On Fri, 2011-03-18 at 18:41 -0700, Shirley Ma wrote:
> > > + /* Drop packet instead of stop queue for better
> performance
> > */
> >
> > I would like to see some justification as to why this is the right
> > way to go and not just papering over the real problem.
>
> Fair. KVM guest virtio_net TX queue stop/restart is pretty expensive,
> which involves:
>
> 1. Guest enable callback: one memory barrier, interrupt flag set
Missed this cost: for history reason, it also involves a guest exit from
I/O write (PCI_QUEUE_NOTIFY).
> 2. Host signals guest: one memory barrier, and a TX interrupt from
> host
> to KVM guest through evenfd_signal.
>
>
> Most of the workload so far we barely see TX over run, except for
> small
> messages TCP_STREAM.
>
> For small message size TCP_STREAM workload, no matter how big the TX
> queue size is, it always causes overrun. I even re-enable the TX queue
> when it's empty, it still hits TX overrun again and again.
>
> Somehow KVM guest and host is not in pace on processing small packets.
> I
> tried to pin each thread to different CPU, it didn't help. So it
> didn't
> seem to be scheduling related.
>
> >From the performance results, we can see dramatically performance
> gain
> with this patch.
>
> I would like to dig out the real reason why host can't in pace with
> guest, but haven't figured it out in month, that's the reason I held
> this patch for a while. However if anyone can give me any ideas on how
> to debug the real problem, I am willing to try it out.
^ permalink raw reply
* Re: [slab poison overwritten] Re: [GIT] Networking
From: Ingo Molnar @ 2011-03-21 17:39 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, torvalds, akpm, netdev, linux-kernel,
Peter Zijlstra, Thomas Gleixner, Arnd Bergmann, Pekka Enberg
In-Reply-To: <20110321164238.GA5303@elte.hu>
here's the same but with kallsyms enabled.
Thanks,
Ingo
[ 9.585627] initcall 0xffffffff81d5b806 returned 0 after 0 usecs
[ 9.588960] calling 0xffffffff81d5b9da @ 1
[ 9.592303] IPVS: Creating netns size=1272 id=0
[ 9.595646] IPVS: __ip_vs_control_init(): alloc_percpu.
[ 9.602298] IPVS: cannot register namespace.
[ 9.605627] IPVS: can't setup control.
[ 9.615628] initcall 0xffffffff81d5b9da returned -12 after 22784 usecs
[ 9.618960] initcall 0xffffffff81d5b9da returned with error code -12
[ 9.622291] calling 0xffffffff81d5c0c0 @ 1
[ 9.625625] IPVS: [wlc] scheduler registered.
[ 9.628957] initcall 0xffffffff81d5c0c0 returned 0 after 3254 usecs
[ 9.632291] calling 0xffffffff81d5c12b @ 1
[ 9.635635] IPVS: [lblc] scheduler registered.
[ 9.638957] initcall 0xffffffff81d5c12b returned 0 after 3254 usecs
[ 9.642290] calling 0xffffffff81d5c167 @ 1
[ 9.645623] IPVS: [dh] scheduler registered.
[ 9.648956] initcall 0xffffffff81d5c167 returned 0 after 3254 usecs
[ 9.652289] calling 0xffffffff81d5c179 @ 1
[ 9.655622] IPVS: [sh] scheduler registered.
[ 9.658955] initcall 0xffffffff81d5c179 returned 0 after 3254 usecs
[ 9.662289] calling 0xffffffff81d5c18b @ 1
[ 9.668955] IPVS: [nq] scheduler registered.
[ 9.672288] initcall 0xffffffff81d5c18b returned 0 after 3254 usecs
[ 9.676859] calling 0xffffffff81d5d589 @ 1
[ 9.679217] initcall 0xffffffff81d5d589 returned 0 after 0 usecs
[ 9.682288] calling 0xffffffff81d5d9fa @ 1
[ 9.685620] IPv4 over IPv4 tunneling driver
[ 9.689135] =============================================================================
[ 9.692285] BUG kmalloc-2048: Poison overwritten
[ 9.692285] -----------------------------------------------------------------------------
[ 9.692285]
[ 9.692285] INFO: 0xffff88003cc2d6c0-0xffff88003cc2d6d7. First byte 0x0 instead of 0x6b
[ 9.692285] INFO: Allocated in 0xffffffff8178ad5c age=29 cpu=0 pid=1
[ 9.692285] INFO: Freed in 0xffffffff8178ac6c age=23 cpu=0 pid=1
[ 9.692285] INFO: Slab 0xffffea0000d4a8c0 objects=15 used=11 fp=0xffff88003cc2d2d0 flags=0x40000000000040c0
[ 9.692285] INFO: Object 0xffff88003cc2d2d0 @offset=21200 fp=0xffff88003cc2e360
[ 9.692285]
[ 9.692285] Bytes b4 0xffff88003cc2d2c0: 00 00 00 00 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a ........ZZZZZZZZ
[ 9.692285] Object 0xffff88003cc2d2d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d2e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d2f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d300: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d310: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d320: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d330: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d340: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d350: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d360: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d370: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d380: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d390: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d3a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d3b0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d3c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d3d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d3e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d3f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d400: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d410: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d420: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d430: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d440: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d450: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d460: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d470: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d480: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d490: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d4a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d4b0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d4c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d4d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d4e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d4f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d500: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d510: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d520: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d530: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d540: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d550: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d560: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d570: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d580: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d590: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d5a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d5b0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d5c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d5d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d5e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d5f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d600: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d610: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d620: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d630: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d640: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d650: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d660: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d670: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d680: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d690: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d6a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d6b0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d6c0: 00 82 8b 01 6b 6b 6b 6b 48 82 cb 3c 00 88 ff ff ....kkkkH.�<..��
[ 9.692285] Object 0xffff88003cc2d6d0: 60 ae d0 81 ff ff ff ff 6b 6b 6b 6b 6b 6b 6b 6b `��.����kkkkkkkk
[ 9.692285] Object 0xffff88003cc2d6e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d6f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d700: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d710: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d720: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d730: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d740: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d750: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d760: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d770: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d780: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d790: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d7a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d7b0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d7c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d7d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d7e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d7f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d800: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d810: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d820: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d830: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d840: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d850: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d860: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d870: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d880: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d890: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d8a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d8b0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d8c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d8d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d8e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d8f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d900: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d910: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d920: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d930: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d940: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d950: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d960: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d970: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d980: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d990: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d9a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d9b0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d9c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d9d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d9e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2d9f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2da00: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2da10: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2da20: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2da30: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2da40: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2da50: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2da60: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2da70: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2da80: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2da90: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2daa0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2dab0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 9.692285] Object 0xffff88003cc2dac0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 kkkkkkkkkkkkkkk�
[ 9.692285] Redzone 0xffff88003cc2dad0: bb bb bb bb bb bb bb bb ��������
[ 9.692285] Padding 0xffff88003cc2db10: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ
[ 9.692285] Pid: 1, comm: swapper Not tainted 2.6.38-tip-08708-g9ad1933-dirty #109455
[ 9.692285] Call Trace:
[ 9.692285] [<ffffffff810c3c3c>] 0xffffffff810c3c3c
[ 9.692285] [<ffffffff810c3f0f>] 0xffffffff810c3f0f
[ 9.692285] [<ffffffff81798fbb>] ? 0xffffffff81798fbb
[ 9.692285] [<ffffffff810c400c>] 0xffffffff810c400c
[ 9.692285] [<ffffffff81798f31>] ? 0xffffffff81798f31
[ 9.692285] [<ffffffff81798f31>] ? 0xffffffff81798f31
[ 9.692285] [<ffffffff81798f31>] ? 0xffffffff81798f31
[ 9.692285] [<ffffffff8193dbb7>] 0xffffffff8193dbb7
[ 9.692285] [<ffffffff8193e253>] 0xffffffff8193e253
[ 9.692285] [<ffffffff810c63bd>] 0xffffffff810c63bd
[ 9.692285] [<ffffffff81798f31>] ? 0xffffffff81798f31
[ 9.692285] [<ffffffff810aba3e>] 0xffffffff810aba3e
[ 9.692285] [<ffffffff81798f31>] 0xffffffff81798f31
[ 9.692285] [<ffffffff81821593>] 0xffffffff81821593
[ 9.692285] [<ffffffff81821675>] 0xffffffff81821675
[ 9.692285] [<ffffffff81821d40>] 0xffffffff81821d40
[ 9.692285] [<ffffffff8136ad34>] ? 0xffffffff8136ad34
[ 9.692285] [<ffffffff81072568>] 0xffffffff81072568
[ 9.692285] [<ffffffff81072832>] 0xffffffff81072832
[ 9.692285] [<ffffffff8178c87b>] 0xffffffff8178c87b
[ 9.692285] [<ffffffff817913db>] 0xffffffff817913db
[ 9.692285] [<ffffffff8179147e>] 0xffffffff8179147e
[ 9.692285] [<ffffffff81d5d9d8>] 0xffffffff81d5d9d8
[ 9.692285] [<ffffffff8178ae06>] 0xffffffff8178ae06
[ 9.692285] [<ffffffff81d5d9fa>] ? 0xffffffff81d5d9fa
[ 9.692285] [<ffffffff81d5d9fa>] ? 0xffffffff81d5d9fa
[ 9.692285] [<ffffffff8178ae65>] 0xffffffff8178ae65
[ 9.692285] [<ffffffff8194c949>] ? 0xffffffff8194c949
[ 9.692285] [<ffffffff8178af96>] 0xffffffff8178af96
[ 9.692285] [<ffffffff81d5da1b>] 0xffffffff81d5da1b
[ 9.692285] [<ffffffff81d25aee>] 0xffffffff81d25aee
[ 9.692285] [<ffffffff81d25c76>] 0xffffffff81d25c76
[ 9.692285] [<ffffffff8194ea44>] 0xffffffff8194ea44
[ 9.692285] [<ffffffff81d25bcf>] ? 0xffffffff81d25bcf
[ 9.692285] [<ffffffff8194ea40>] ? 0xffffffff8194ea40
[ 9.692285] FIX kmalloc-2048: Restoring 0xffff88003cc2d6c0-0xffff88003cc2d6d7=0x6b
[ 9.692285]
[ 9.692285] FIX kmalloc-2048: Marking all objects used
[ 9.692586] initcall 0xffffffff81d5d9fa returned 0 after 6509 usecs
[ 9.695620] calling 0xffffffff81d5da59 @ 1
[ 9.698952] GRE over IPv4 demultiplexor driver
[ 9.702287] initcall 0xffffffff81d5da59 returned 0 after 3254 usecs
[ 9.705619] calling 0xffffffff81d5da99 @ 1
[ 9.708953] initcall 0xffffffff81d5da99 returned 0 after 0 usecs
[ 9.712285] calling 0xffffffff81d5db01 @ 1
[ 9.715619] initcall 0xffffffff81d5db01 returned 0 after 0 usecs
[ 9.718951] calling 0xffffffff81d5db33 @ 1
[ 9.722285] initcall 0xffffffff81d5db33 returned 0 after 0 usecs
[ 9.725618] calling 0xffffffff81d5db4a @ 1
[ 9.728951] initcall 0xffffffff81d5db4a returned 0 after 0 usecs
[ 9.732284] calling 0xffffffff8183391a @ 1
[ 9.735618] initcall 0xffffffff8183391a returned 0 after 0 usecs
[ 9.738950] calling 0xffffffff81d5f616 @ 1
[ 9.742383] initcall 0xffffffff81d5f616 returned 0 after 0 usecs
[ 9.745616] calling 0xffffffff81d5f777 @ 1
[ 9.748986] initcall 0xffffffff81d5f777 returned 0 after 0 usecs
[ 9.752283] calling 0xffffffff81d5f895 @ 1
[ 9.755616] initcall 0xffffffff81d5f895 returned 0 after 0 usecs
[ 9.758949] calling 0xffffffff81d5f8ac @ 1
[ 9.762283] initcall 0xffffffff81d5f8ac returned 0 after 0 usecs
[ 9.765615] calling 0xffffffff81d5f8be @ 1
[ 9.768948] initcall 0xffffffff81d5f8be returned 0 after 0 usecs
[ 9.772281] calling 0xffffffff81d5f8e0 @ 1
[ 9.775634] ip_tables: (C) 2000-2006 Netfilter Core Team
[ 9.778948] initcall 0xffffffff81d5f8e0 returned 0 after 3254 usecs
[ 9.782281] calling 0xffffffff81d5f9e6 @ 1
[ 9.785650] initcall 0xffffffff81d5f9e6 returned 0 after 0 usecs
[ 9.788947] calling 0xffffffff81d5faee @ 1
[ 9.792304] initcall 0xffffffff81d5faee returned 0 after 0 usecs
[ 9.795613] calling 0xffffffff81d5fbc7 @ 1
[ 9.798970] initcall 0xffffffff81d5fbc7 returned 0 after 0 usecs
[ 9.802280] calling 0xffffffff81d5fc15 @ 1
[ 9.805613] initcall 0xffffffff81d5fc15 returned 0 after 0 usecs
[ 9.808946] calling 0xffffffff81d5fc27 @ 1
[ 9.812285] ipt_CLUSTERIP: ClusterIP Version 0.8 loaded successfully
[ 9.815612] initcall 0xffffffff81d5fc27 returned 0 after 3254 usecs
[ 9.818945] calling 0xffffffff81d5fcba @ 1
[ 9.822281] initcall 0xffffffff81d5fcba returned 0 after 0 usecs
[ 9.825611] calling 0xffffffff81d5fcf2 @ 1
[ 9.828967] initcall 0xffffffff81d5fcf2 returned 0 after 0 usecs
[ 9.832278] calling 0xffffffff81d5fd67 @ 1
[ 9.835611] initcall 0xffffffff81d5fd67 returned 0 after 0 usecs
[ 9.838944] calling 0xffffffff81d5fd79 @ 1
[ 9.842278] TCP westwood registered
[ 9.845610] initcall 0xffffffff81d5fd79 returned 0 after 3254 usecs
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox