* [PATCH 1/3] [BUGFIX] memcg/tcp : fix to see use_hierarchy in tcp memcontrol cgroup
From: KAMEZAWA Hiroyuki @ 2012-03-29 7:03 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki; +Cc: Glauber Costa, netdev, David Miller, Andrew Morton
In-Reply-To: <4F7408B7.9090706@jp.fujitsu.com>
Now, tcp memory control cgroup ignores memcg's use_hierarchy value
and act as use_hierarchy=1 always. After this patch, tcp memcontrol will
work as memcg is designed.
Note:
I know there is a discussion to remove use_hierarchy but this is BUG, now.
Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
---
include/linux/memcontrol.h | 3 +++
mm/memcontrol.c | 5 +++++
net/ipv4/tcp_memcontrol.c | 2 +-
3 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index f94efd2..e116b7c 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -199,6 +199,9 @@ void mem_cgroup_split_huge_fixup(struct page *head);
bool mem_cgroup_bad_page_check(struct page *page);
void mem_cgroup_print_bad_page(struct page *page);
#endif
+
+bool mem_cgroup_use_hierarchy(struct mem_cgroup *memcg);
+
#else /* CONFIG_CGROUP_MEM_RES_CTLR */
struct mem_cgroup;
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 7d698df..467881f 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -867,6 +867,11 @@ struct mem_cgroup *try_get_mem_cgroup_from_mm(struct mm_struct *mm)
return memcg;
}
+bool mem_cgroup_use_hierarchy(struct mem_cgroup *memcg)
+{
+ return memcg->use_hierarchy;
+}
+
/**
* mem_cgroup_iter - iterate over memory cgroup hierarchy
* @root: hierarchy root
diff --git a/net/ipv4/tcp_memcontrol.c b/net/ipv4/tcp_memcontrol.c
index e795272..32764a6 100644
--- a/net/ipv4/tcp_memcontrol.c
+++ b/net/ipv4/tcp_memcontrol.c
@@ -75,7 +75,7 @@ int tcp_init_cgroup(struct cgroup *cgrp, struct cgroup_subsys *ss)
tcp->tcp_memory_pressure = 0;
parent_cg = tcp_prot.proto_cgroup(parent);
- if (parent_cg)
+ if (parent_cg && mem_cgroup_use_hierarchy(parent))
res_parent = parent_cg->memory_allocated;
res_counter_init(&tcp->tcp_memory_allocated, res_parent);
--
1.7.4.1
^ permalink raw reply related
* [BUGFIX][PATCH 0/3] memcg: tcp memcontrol fixes.
From: KAMEZAWA Hiroyuki @ 2012-03-29 7:01 UTC (permalink / raw)
To: Glauber Costa, netdev; +Cc: David Miller, Andrew Morton, kamezawa.hiroyu
I'm very sorry if you received this e-mail twice.
==
This series is 3 bugfixes for memcg's kmem.tcp memory controller.
Maybe this should go via network tree.
(CC akpm for noticing an ugly change in res_counter.)
All patches are generated onto today linus's git tree.
Brief description:
Patch 1/3 .... tcp memcontrol doesn't see memcg's use_hierarchy value. Fix it.
Patch 2/3 and 3/3 ....
Because tcp memcontrol doesn't do any accounting when limit=RESOUCE_MAX,
there will be account leakage when limit is changed. This can trigger
WARN_ON() in res_counter which checks usage >= 0.
Patch 2/3 .... don't call static_key_slow_dec(&memcg_socket_limit_enabled) until
a cgroup under accounted is destroyed.
Patch 3/3 .... add res_counter_uncharge_nowarn() to ignore leakage.
Thanks,
-Kame
^ permalink raw reply
* Re: [PATCH] f_phonet: fix skb truesize underestimation
From: David Miller @ 2012-03-29 6:51 UTC (permalink / raw)
To: remi.denis-courmont-xNZwKgViW5gAvxtiuMwx3w
Cc: eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
balbi-l0cyMroinI0
In-Reply-To: <1377643.vUarymgFD1@hector>
From: Rémi Denis-Courmont <remi.denis-courmont-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org>
Date: Thu, 29 Mar 2012 09:30:32 +0300
> I guess I should use my personal email instead...
nokia.com tends to eat 2 out of every 3 mailing list postings
on vger.kernel.org, so yes I'd say using person email would
be a good idea
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] f_phonet: fix skb truesize underestimation
From: Eric Dumazet @ 2012-03-29 6:46 UTC (permalink / raw)
To: Rémi Denis-Courmont
Cc: ext David Miller, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
balbi-l0cyMroinI0
In-Reply-To: <1377643.vUarymgFD1@hector>
On Thu, 2012-03-29 at 09:30 +0300, Rémi Denis-Courmont wrote:
> Le mardi 27 mars 2012 22:51:09 ext David Miller a écrit :
> > From: Eric Dumazet <eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Date: Tue, 27 Mar 2012 06:04:02 -0700
> >
> > > Now skb_add_rx_frag() has a truesize parameter, we can fix f_phonet to
> > > properly account truesize of each fragment : a full page.
> > >
> > > Signed-off-by: Eric Dumazet <eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> >
> > Applied.
>
> Sorry for not reviewing. My evil corporate mail transfer agent apparently ate
> that patch :-(
>
> I guess I should use my personal email instead...
>
Thats true, I got a funny reject from your mail server, stating :
"Your domain is blocked with bad reputation defined by CommTouch: ...
(state 13)"
gmail.com has bad reputation ? Come on !
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* 答复: [PATCH] set fake_rtable's dst to NULL to avoid kernel Oops.
From: Peter Huang (Peng) @ 2012-03-29 6:40 UTC (permalink / raw)
To: 'Eric Dumazet'
Cc: linux-kernel, harry.majun, zhoukang7, 'netdev'
In-Reply-To: <1333002975.2325.82.camel@edumazet-glaptop>
We already check current kernel-3.3, it has the same problem.
I am not very sure that if this modify could cause other problems or not,
Because I don't know where fake_rtable was used.
-----邮件原件-----
发件人: Eric Dumazet [mailto:eric.dumazet@gmail.com]
发送时间: 2012年3月29日 14:36
收件人: Peter Huang (Peng)
抄送: linux-kernel@vger.kernel.org; harry.majun@huawei.com; zhoukang7@huawei.com; netdev
主题: Re: [PATCH] set fake_rtable's dst to NULL to avoid kernel Oops.
On Thu, 2012-03-29 at 14:21 +0800, Peter Huang (Peng) wrote:
> In our environment, we encountered a kernel Oops problem, and caused a
> restart.
>
CC netdev, since its more appropriate
> Below are what happened:
> kernel: 2.6.32.36-0.5-xen OS:xen + dom-0 + guest(rhel5.5)
> 1.destroy one VM.
> 2.ipsan path have some problem and make destroy process delayed about 10s.
> 3.customer defined script find that VM no longer exsit through libvirt API.
> 4.br0(related to the VM we are destoryed before) was deleted by the script.
> 5.delayed VM destroy process come to tap device releasing, this will
> decrement
> skb->_skb_dst's reference count(skb->_skb_dst points to fake_rtable), but
> br0
> deleting already released this struct, and unfortunately OS reused this
> memory
> and marked it read-only.
> 6.Oops happened, and caused restart.
>
> After analyzing the stack dump info, we find out that during our VM destroy,
> lots of ipv6 multicast pkts
> exsited, and skb->_skb_dst pointed to (stuct)fake_rtable.
> through kernel source greping, will only find one reference to fake_rtable's
> MTU setting.
>
> So I'm wondering that what fake_rtable stands for, and where we are using
> it.
> If fake_rtable's dst is not used, we can make dst as NULL to avoid our
> problem,.
> I also added the patch which modified the skb->_skb_dst to NULL when
> "skb->_skb_dst == (unsigned long)&to->br->fake_rtable".
>
> BTW, we also verified a similar senario on kernel-3.3, that br0 has attached
> eth0 and eth1, eth1 was
> connected to our guest which will multicast ipv6 packets, and you can get an
> "WARNING: at net/core/dst.c:274 dst_release+0x6d/0x70()"
> by using the fake_rtable_verify.c attached,
> #gcc fake_rtable_verify.c
> #./a.out &
> #sleep 30 //make sure ipv6 pkts was in tap00's receiving queue.
> #ifconfig br0 down
> #brctl delbr br0 //delete br0, will also delete net_device's fake_rtable.
> #sleep 50
> #kill -9 `pidof a.out` //tap00's delete will do dst_release, and this will
> write to the memory already freed.
>
> Below is the Oops stack dump info:
> ////////////////////////////////////////////////////////////////////////////
> ///
> RIP: e030:[<ffffffff802ddbd1>]
> <ffffffff802ddbd1>{dst_release+0x11}
> RSP: e02b:ffff88008b185b70 EFLAGS: 00010286
> RAX: 00000000ffffffff RBX: ffff880033d184c0 RCX: 0000000000000000
> RDX: ffff88008b54f080 RSI: 0000000012df12df RDI: ffff88008b54efc0
> RBP: ffff8800f4a3f500 R08: 0000000000000001 R09: 0000000000000000
> R10: 0000000000000002 R11: ffffffff8018c1e0 R12: ffff8800f4a3f400
> R13: 0000000000000001 R14: ffff8800f4a3f4e0 R15: ffff8800351030c0
> FS: 00007f4cbd080700(0000) GS:ffff880002008000(0000) knlGS:0000000000000000
> CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: ffff88008b54f080 CR3: 000000008a27c000 CR4: 0000000000002620
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> <ffffffff80009b05>{dump_trace+0x65}
> <ffffffff8037d897>{notifier_call_chain+0x37}
> <ffffffff8005a1ed>{notify_die+0x2d}
> <ffffffff8037bd0b>{__die+0x8b}
> <ffffffff8001bed1>{no_context+0xd1}
> <ffffffff8001c1f5>{__bad_area_nosemaphore+0x175}
> <ffffffff8037b298>{page_fault+0x28}
> <ffffffff802ddbd1>{dst_release+0x11}
> <ffffffff802cd69d>{skb_release_head_state+0xbd}
> <ffffffff802cd369>{__kfree_skb+0x9}
> <ffffffff802edaab>{pfifo_fast_reset+0x5b}
> <ffffffff802edbd3>{qdisc_reset+0x13}
> <ffffffff802edcc7>{dev_deactivate_queue+0x57}
> <ffffffff802ee4bf>{dev_deactivate+0x3f}
> <ffffffff802d9575>{dev_close+0x65}
> <ffffffff802d960e>{rollback_registered+0x3e}
> <ffffffff802d9715>{unregister_netdevice+0x15}
> <ffffffffa0807655>{tun:tun_chr_close+0xe5}
> <ffffffff800d9edd>{__fput+0xcd}
> <ffffffff800d6076>{filp_close+0x56}
> <ffffffff8003fd9a>{put_files_struct+0x7a}
> <ffffffff80040fb2>{do_exit+0x752}
> <ffffffff800410ef>{do_group_exit+0x3f}
> <ffffffff8004d9d9>{get_signal_to_deliver+0x229}
> <ffffffff80006acd>{do_notify_resume+0x11d}
> <ffffffff8000763c>{int_signal+0x12}
> [<00007f4cbc7fd57d>]
> ////////////////////////////////////////////////////////////////////////////
> ///
>
> Signed-off-by: Peter Huang(Peng) <peter.huangpeng@huawei.com>
> ---
> diff -Nur a/net/bridge/br_forward.c b/net/bridge/br_forward.c
> @@ -91,6 +91,9 @@
> skb->dev = to->dev;
> skb_forward_csum(skb);
>
> + if (skb->_skb_dst == (unsigned long)&to->br->fake_rtable)
> + skb_dst_set(skb, NULL);
> +
> NF_HOOK(NFPROTO_BRIDGE, NF_BR_FORWARD, skb, indev, skb->dev,
> br_forward_finish);
> }
Did you check current kernel has this bug ?
I remember we already fix this, maybe you need a backport.
^ permalink raw reply
* Re: [PATCH] set fake_rtable's dst to NULL to avoid kernel Oops.
From: Eric Dumazet @ 2012-03-29 6:36 UTC (permalink / raw)
To: Peter Huang (Peng); +Cc: linux-kernel, harry.majun, zhoukang7, netdev
In-Reply-To: <002501cd0d74$317fd100$947f7300$%huangpeng@huawei.com>
On Thu, 2012-03-29 at 14:21 +0800, Peter Huang (Peng) wrote:
> In our environment, we encountered a kernel Oops problem, and caused a
> restart.
>
CC netdev, since its more appropriate
> Below are what happened:
> kernel: 2.6.32.36-0.5-xen OS:xen + dom-0 + guest(rhel5.5)
> 1.destroy one VM.
> 2.ipsan path have some problem and make destroy process delayed about 10s.
> 3.customer defined script find that VM no longer exsit through libvirt API.
> 4.br0(related to the VM we are destoryed before) was deleted by the script.
> 5.delayed VM destroy process come to tap device releasing, this will
> decrement
> skb->_skb_dst's reference count(skb->_skb_dst points to fake_rtable), but
> br0
> deleting already released this struct, and unfortunately OS reused this
> memory
> and marked it read-only.
> 6.Oops happened, and caused restart.
>
> After analyzing the stack dump info, we find out that during our VM destroy,
> lots of ipv6 multicast pkts
> exsited, and skb->_skb_dst pointed to (stuct)fake_rtable.
> through kernel source greping, will only find one reference to fake_rtable's
> MTU setting.
>
> So I'm wondering that what fake_rtable stands for, and where we are using
> it.
> If fake_rtable's dst is not used, we can make dst as NULL to avoid our
> problem,.
> I also added the patch which modified the skb->_skb_dst to NULL when
> "skb->_skb_dst == (unsigned long)&to->br->fake_rtable".
>
> BTW, we also verified a similar senario on kernel-3.3, that br0 has attached
> eth0 and eth1, eth1 was
> connected to our guest which will multicast ipv6 packets, and you can get an
> "WARNING: at net/core/dst.c:274 dst_release+0x6d/0x70()"
> by using the fake_rtable_verify.c attached,
> #gcc fake_rtable_verify.c
> #./a.out &
> #sleep 30 //make sure ipv6 pkts was in tap00's receiving queue.
> #ifconfig br0 down
> #brctl delbr br0 //delete br0, will also delete net_device's fake_rtable.
> #sleep 50
> #kill -9 `pidof a.out` //tap00's delete will do dst_release, and this will
> write to the memory already freed.
>
> Below is the Oops stack dump info:
> ////////////////////////////////////////////////////////////////////////////
> ///
> RIP: e030:[<ffffffff802ddbd1>]
> <ffffffff802ddbd1>{dst_release+0x11}
> RSP: e02b:ffff88008b185b70 EFLAGS: 00010286
> RAX: 00000000ffffffff RBX: ffff880033d184c0 RCX: 0000000000000000
> RDX: ffff88008b54f080 RSI: 0000000012df12df RDI: ffff88008b54efc0
> RBP: ffff8800f4a3f500 R08: 0000000000000001 R09: 0000000000000000
> R10: 0000000000000002 R11: ffffffff8018c1e0 R12: ffff8800f4a3f400
> R13: 0000000000000001 R14: ffff8800f4a3f4e0 R15: ffff8800351030c0
> FS: 00007f4cbd080700(0000) GS:ffff880002008000(0000) knlGS:0000000000000000
> CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: ffff88008b54f080 CR3: 000000008a27c000 CR4: 0000000000002620
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> <ffffffff80009b05>{dump_trace+0x65}
> <ffffffff8037d897>{notifier_call_chain+0x37}
> <ffffffff8005a1ed>{notify_die+0x2d}
> <ffffffff8037bd0b>{__die+0x8b}
> <ffffffff8001bed1>{no_context+0xd1}
> <ffffffff8001c1f5>{__bad_area_nosemaphore+0x175}
> <ffffffff8037b298>{page_fault+0x28}
> <ffffffff802ddbd1>{dst_release+0x11}
> <ffffffff802cd69d>{skb_release_head_state+0xbd}
> <ffffffff802cd369>{__kfree_skb+0x9}
> <ffffffff802edaab>{pfifo_fast_reset+0x5b}
> <ffffffff802edbd3>{qdisc_reset+0x13}
> <ffffffff802edcc7>{dev_deactivate_queue+0x57}
> <ffffffff802ee4bf>{dev_deactivate+0x3f}
> <ffffffff802d9575>{dev_close+0x65}
> <ffffffff802d960e>{rollback_registered+0x3e}
> <ffffffff802d9715>{unregister_netdevice+0x15}
> <ffffffffa0807655>{tun:tun_chr_close+0xe5}
> <ffffffff800d9edd>{__fput+0xcd}
> <ffffffff800d6076>{filp_close+0x56}
> <ffffffff8003fd9a>{put_files_struct+0x7a}
> <ffffffff80040fb2>{do_exit+0x752}
> <ffffffff800410ef>{do_group_exit+0x3f}
> <ffffffff8004d9d9>{get_signal_to_deliver+0x229}
> <ffffffff80006acd>{do_notify_resume+0x11d}
> <ffffffff8000763c>{int_signal+0x12}
> [<00007f4cbc7fd57d>]
> ////////////////////////////////////////////////////////////////////////////
> ///
>
> Signed-off-by: Peter Huang(Peng) <peter.huangpeng@huawei.com>
> ---
> diff -Nur a/net/bridge/br_forward.c b/net/bridge/br_forward.c
> @@ -91,6 +91,9 @@
> skb->dev = to->dev;
> skb_forward_csum(skb);
>
> + if (skb->_skb_dst == (unsigned long)&to->br->fake_rtable)
> + skb_dst_set(skb, NULL);
> +
> NF_HOOK(NFPROTO_BRIDGE, NF_BR_FORWARD, skb, indev, skb->dev,
> br_forward_finish);
> }
Did you check current kernel has this bug ?
I remember we already fix this, maybe you need a backport.
^ permalink raw reply
* Re: [PATCH] f_phonet: fix skb truesize underestimation
From: Rémi Denis-Courmont @ 2012-03-29 6:30 UTC (permalink / raw)
To: ext David Miller
Cc: eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
balbi-l0cyMroinI0
In-Reply-To: <20120327.225109.752822925052179338.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Le mardi 27 mars 2012 22:51:09 ext David Miller a écrit :
> From: Eric Dumazet <eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date: Tue, 27 Mar 2012 06:04:02 -0700
>
> > Now skb_add_rx_frag() has a truesize parameter, we can fix f_phonet to
> > properly account truesize of each fragment : a full page.
> >
> > Signed-off-by: Eric Dumazet <eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>
> Applied.
Sorry for not reviewing. My evil corporate mail transfer agent apparently ate
that patch :-(
I guess I should use my personal email instead...
--
Rémi Denis-Courmont
http://www.remlab.net/
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: bpf_slow_path: sibling call to `skb_copy_bits' not allowed multiple TOCs (ppc)
From: Stephen Rothwell @ 2012-03-29 3:30 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: netdev, linuxppc-dev, linux-next
In-Reply-To: <CAP=VYLqwbjNDQ-TTbs_6cH4X2MMzy=MAFy4=R116zGL8a6qUag@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 814 bytes --]
Hi Paul,
On Wed, 28 Mar 2012 20:54:56 -0400 Paul Gortmaker <paul.gortmaker@windriver.com> wrote:
>
> coverage. Even in the absence of the skb error, it still fails to link with:
>
> "powerpc-linux-ld: TOC section size exceeds 64k"
>
> i.e. it never links into anything a person could actually try and boot anyway.
>
> So, just knowing "yes that is bogus because you've got a giant kernel
> with multiple TOC" would be useful information here.
This last message has been known for a long time and would require us to
change the way we link the kernel to fix. I had a go at it a year or so
ago, but ran into binutils bugs :-(
The other message may be a result of the TOC section size problem, but I
am not sure.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH V3 0/6] net/mlx4_en: DCB QoS support
From: Eric Dumazet @ 2012-03-29 3:14 UTC (permalink / raw)
To: Or Gerlitz
Cc: David S. Miller, netdev, Roland Dreier, Yevgeny Petrilin,
Oren Duer, Amir Vadai, John Fastabend, Amir Vadai
In-Reply-To: <CAJZOPZLLJdQX4i_WhV8Bo5UHaxndFDwf873n8ZTCPqXq7JrMiw@mail.gmail.com>
Le jeudi 29 mars 2012 à 00:21 +0200, Or Gerlitz a écrit :
> For the ratelimit Eric D. provided feedback and it was implemented
> along his suggestion,
My suggestion was exactly the following :
/sys/class/net/eth2/qos/0/ratelimit
...
/sys/class/net/eth2/qos/7/ratelimit
> and now John and Ben have other suggestions,
I dont think so.
Amir provided in V2 something that was not what I suggested.
/sys/class/net/eth2/ratelimit/tc0
...
/sys/class/net/eth2/ratelimit/tc7
And this is where John, Ben were complaining.
[ Obviously I totally agree with them ]
^ permalink raw reply
* Re: Crash in __netif_receive_skb
From: Avleen Vig @ 2012-03-29 3:01 UTC (permalink / raw)
To: linux-kernel, netdev
In-Reply-To: <CAMjP1Kka6MmT2zLc95ZQ=vigS6w9diS9-tawzdUdhbzzfzMh3w@mail.gmail.com>
On Wed, Mar 28, 2012 at 8:31 PM, Avleen Vig <avleen@gmail.com> wrote:
> Hi folks, someone in #kernel recommended I email these two lists. Hope
> they're the right place.
>
> We're running 2.6.32-220.4.1.el6.x86_64 on Centos 6.2, and getting a
> repeated crash:
> https://gist.github.com/2231998
>
> We can make this happen pretty easily just by passing some network
> traffic and waiting a while.
> I couldn't find any references to this particular issue.
> I have vmcore files and am happy to dig into it if it would help (as
> long as someone can tell me what to do :))
I hope this debugging is legit, I'm really new to this level of insight.
I think the problem is in include/linux/netpoll.h, at the "if"
statement at line 86:
static inline int netpoll_receive_skb(struct sk_buff *skb)
{
if (!list_empty(&skb->dev->napi_list))
return netpoll_rx(skb);
return 0;
}
This is based on poking around in the crash dump:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000060
IP: [<ffffffff8142bb40>] __netif_receive_skb+0x60/0x6e0
crash> dis -rl ffffffff8142bb40
....
/usr/src/debug/kernel-2.6.32-220.7.1.el6/linux-2.6.32-220.7.1.el6.x86_64/include/linux/netpoll.h:
86
0xffffffff8142bb33 <__netif_receive_skb+83>: mov 0x20(%rbx),%r12
0xffffffff8142bb37 <__netif_receive_skb+87>: mov %r12,-0x38(%rbp)
0xffffffff8142bb3b <__netif_receive_skb+91>: lea 0x60(%r12),%rax
0xffffffff8142bb40 <__netif_receive_skb+96>: cmp %rax,0x60(%r12)
I *think* this means that "&skb->dev->napi_list" is null when we're
trying to compare it, rather than being a list.
If it matters, this is inside LXC containers.
^ permalink raw reply
* Re: [PATCH] f_phonet: fix skb truesize underestimation
From: Paul Gortmaker @ 2012-03-29 2:15 UTC (permalink / raw)
To: balbi-l0cyMroinI0
Cc: David Miller, eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
remi.denis-courmont-xNZwKgViW5gAvxtiuMwx3w
In-Reply-To: <20120328124314.GG28319-S8G//mZuvNWo5Im9Ml3/Zg@public.gmane.org>
On Wed, Mar 28, 2012 at 8:43 AM, Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org> wrote:
> On Wed, Mar 28, 2012 at 05:33:10AM -0400, David Miller wrote:
>> From: Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org>
>> Date: Wed, 28 Mar 2012 11:55:36 +0300
>>
>> > On Tue, Mar 27, 2012 at 10:51:09PM -0400, David Miller wrote:
>> >> From: Eric Dumazet <eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> >> Date: Tue, 27 Mar 2012 06:04:02 -0700
>> >>
>> >> > Now skb_add_rx_frag() has a truesize parameter, we can fix f_phonet to
>> >> > properly account truesize of each fragment : a full page.
>> >> >
>> >> > Signed-off-by: Eric Dumazet <eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> >>
>> >> Applied.
>> >
>> > did you apply both patches ?
>>
>> You never need to ask me these kinds of questions, you can
>> either check my GIT tree or look at:
>>
>> http://patchwork.ozlabs.org/project/netdev/list/?state=3
>
> I'm asking because drivers/usb/gadget/ should either go through me or
> you should wait for my Acked-by. Now it's too late for that, but next
> time for my Ack.
Hi Felipe,
Being in the MAINTAINERS file is best interpreted as "I care about
this driver/code/subsystem, and I'll do my best to fix/integrate for it,
and I want to know about changes to it".
It has never meant that all patches to that MAINTAINER's code must
be OK'd by that one particular maintainer before being committed.
In the last twenty years, I can't ever recall any one driver/subsystem
where one individual had the ultimate veto (excluding Linus). And
that is a good thing.
If a commit has dependencies to low level skb accounting, then it
makes perfect sense for it to be in the tree where those accounting
changes are made. Even more sense for it to be done by the
people who know those internals better than anyone else.
Speaking for myself, if I had networking code that Eric and Dave
made changes to, I'd be pretty damn happy that smarter people
than myself did the changes for me, and that they were nice enough
to have CC'd me on the changes as a courtesy.
Just my $0.02.
Paul.
>
> --
> balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: compat-wireless releases based on v3.3
From: Richard Farina @ 2012-03-29 1:45 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: linux-kernel, linux-wireless, linux-bluetooth, netdev,
lf_driver_backport
In-Reply-To: <CAB=NE6WFM-BPQ41kPaod-7qkHnT5MXCUc2hdKXDVzrdPq2brjA@mail.gmail.com>
On 03/28/12 03:43, Luis R. Rodriguez wrote:
> On Wed, Mar 28, 2012 at 12:19 AM, Richard Farina <sidhayn@gmail.com> wrote:
>> /var/tmp/portage/net-wireless/compat-wireless-3.3/work/compat-wireless-3.3-1-n/drivers/net/wireless/ath/carl9170/tx.c:
>> In function 'carl9170_tx_ps_drop':
>> /var/tmp/portage/net-wireless/compat-wireless-3.3/work/compat-wireless-3.3-1-n/drivers/net/wireless/ath/carl9170/tx.c:1248:26:
>> error: 'IEEE80211_TX_CTL_POLL_RESPONSE' undeclared (first use in this
>> function)
> linux-next-cherry-picks/0007-mac80211-handle-non-bufferable-MMPDUs-correctly.patch
>
> is to be blamed for. This is fixed, new tarball:
>
> http://www.orbit-lab.org/kernel/compat-wireless-3-stable/v3.3/compat-wireless-3.3-2-n.tar.bz2
> sha1sum: dd18cfabbe705a75440fd7fbe50a09d5fe34bb70
Confirmed, I am able to build 3.3-2-n with no issues.
Thanks!
-Rick
> Thanks for reporting this. Just FYI -- I am working to use ckmake on
> compat-wireless.git to build test against all supported kernels prior
> to release just as I am doing now for compat.git, but the current
> development cycle still a few items which require a bit of work to
> backport to fix compilation against older kernels. That is the goal
> though, so that future releases area always guaranteed to compile
> against all supported stable kernel releases listed on kernel.org.
>
> Luis
>
^ permalink raw reply
* Crash in __netif_receive_skb
From: Avleen Vig @ 2012-03-29 1:31 UTC (permalink / raw)
To: linux-kernel, netdev
Hi folks, someone in #kernel recommended I email these two lists. Hope
they're the right place.
We're running 2.6.32-220.4.1.el6.x86_64 on Centos 6.2, and getting a
repeated crash:
https://gist.github.com/2231998
We can make this happen pretty easily just by passing some network
traffic and waiting a while.
I couldn't find any references to this particular issue.
I have vmcore files and am happy to dig into it if it would help (as
long as someone can tell me what to do :))
Help?
^ permalink raw reply
* bpf_slow_path: sibling call to `skb_copy_bits' not allowed multiple TOCs (ppc)
From: Paul Gortmaker @ 2012-03-29 0:54 UTC (permalink / raw)
To: netdev; +Cc: linuxppc-dev, linux-next
Hi all,
Wondering if anyone has researched this, before I waste more time on it.
The linux-next build of powerpc-allyesconfig has for quite some time shown this:
LD .tmp_vmlinux1
powerpc-linux-ld: arch/powerpc/net/built-in.o: In function `bpf_slow_path_word':
(.text+0x90): sibling call optimization to `skb_copy_bits' does not
allow automatic
multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or
make `skb_copy_bits' extern
We get the same error for s/word/half/ and s/word/byte/ and s/word/msh/
Visually "bisecting" the linux-next builds shows the following:
good: Dec 7th, 2011: http://kisskb.ellerman.id.au/kisskb/buildresult/5059024/
bad: Dec 8th, 2011: http://kisskb.ellerman.id.au/kisskb/buildresult/5062069/
I wouldn't be surprised if this was some kind of size thing that doesn't matter
in the real world, as the powerpc-allyesconfig is really only of value for build
coverage. Even in the absence of the skb error, it still fails to link with:
"powerpc-linux-ld: TOC section size exceeds 64k"
i.e. it never links into anything a person could actually try and boot anyway.
So, just knowing "yes that is bogus because you've got a giant kernel
with multiple TOC" would be useful information here.
Thanks,
Paul.
^ permalink raw reply
* Re: [PATCH V3 0/6] net/mlx4_en: DCB QoS support
From: David Miller @ 2012-03-28 23:23 UTC (permalink / raw)
To: or.gerlitz
Cc: netdev, roland, yevgenyp, oren, amirv, john.r.fastabend,
eric.dumazet, amirv
In-Reply-To: <CAJZOPZLLJdQX4i_WhV8Bo5UHaxndFDwf873n8ZTCPqXq7JrMiw@mail.gmail.com>
From: Or Gerlitz <or.gerlitz@gmail.com>
Date: Thu, 29 Mar 2012 00:21:57 +0200
> For the ratelimit Eric D. provided feedback and it was implemented
> along his suggestion,
> and now John and Ben have other suggestions, so need clear feedback
> here not to implement this in 2-3 different ways, and this is the
> easier piece. As for the HW QoS, the discussion continues.
I think the ratelimit stuff needs to be an optional attribute to
the existing dcbnl stuff, and I think that's in line with the
most recent suggestions you've received.
Definitely not module parameters or sysctl knobs, anything but that.
^ permalink raw reply
* [PATCH] net: lpc_eth: Fix rename of dev_hw_addr_random
From: Roland Stigge @ 2012-03-28 22:36 UTC (permalink / raw)
To: netdev, linux-kernel, kevin.wells, linux-arm-kernel; +Cc: Roland Stigge
In parallel to the integration of lpc_eth.c, dev_hw_addr_random() has been
renamed to eth_hw_addr_random(). This patch fixes it also in the new driver
lpc_eth.c.
Signed-off-by: Roland Stigge <stigge@antcom.de>
---
drivers/net/ethernet/nxp/lpc_eth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-2.6.orig/drivers/net/ethernet/nxp/lpc_eth.c
+++ linux-2.6/drivers/net/ethernet/nxp/lpc_eth.c
@@ -1441,7 +1441,7 @@ static int lpc_eth_drv_probe(struct plat
}
#endif
if (!is_valid_ether_addr(ndev->dev_addr))
- dev_hw_addr_random(ndev, ndev->dev_addr);
+ eth_hw_addr_random(ndev);
/* Reset the ethernet controller */
__lpc_eth_reset(pldat);
^ permalink raw reply
* maranello for linux-current [b43 driver]
From: Jim Cromie @ 2012-03-28 22:24 UTC (permalink / raw)
To: Bo Han, netdev
you may have heard of maranello, a project to add
partial packet recovery to 80211, by adding block checksums
on transmit, validating them or re-requesting retransmit
of corrupted blocks.
http://www.cs.umd.edu/projects/maranello/
the code at the page is for 2.6.29-rc2
Ive taken it, did some refactoring to ease merging,
and merged in each linux release, up to 3.3
The refactoring is:
- move code from include/net/mac80211.h utils.c to
drivers/net/wireless/maranello.*
this makes it somewhat common, but more isolated overall,
and reduces merge conflicts due to continued evolution of those files.
I imagine new code would eventually go back to the original files, but
not for a while.
- move most of new code in each *.c file to *_mnlo.c
fn decls added to corresponding *.h
again, this code probably would be moved back to original *.c, but not yet.
After all the merges, I compiled, and found some errors.
I had problems building plain 2.6.29-rc2, and several later releases,
so punted on compiling every step.
The compile errors are fixed on top of the merges, but ideally should be
rearranged to fix each release. This requires more git-fu than I possess,
and IIUC, netdev ML is more interested in patches to linux-current.
Repeating: this is only compile tested, I dont have a b43 based wifi card
in my desk/lap-tops.
I do have a WRT54G router, currently running openWRT 10.03
which does have a b43 wifi chip. I intend to try putting this code
there eventually,
but that may take a while yet, and cannot test maranello itself anyway.
Having split maranello code into new files, I have some misgivings about
that approach - it simplified merges, but at the cost of not seeing
the underlying conflicts. The compiler told me about some, surely others lurk.
So I guess Im seeking advice:
- what did I break
- what happens when the driver is tested
- whether to repeat this merge-effort w/o the split
- why did earlier releases fail to build
[jimc@groucho linux-2.6]$ git checkout v2.6.29
[jimc@groucho build-dell-2]$ make xconfig
Makefile:23: *** mixed implicit and normal rules. Stop.
I also see breakage on unrelated stuff (that builds fine on mainline)
[jimc@groucho build-dell-2]$ make
AS arch/x86/xen/xen-asm_64.o
/home/jimc/projects/lx/linux-2.6/arch/x86/xen/xen-asm_64.S:
Assembler messages:
/home/jimc/projects/lx/linux-2.6/arch/x86/xen/xen-asm_64.S:48:
Error: unsupported for `mov'
...
the tree is here:
https://github.com/jimc/linux-2.6/tree/maranello/released-split
Im happy to open it up for collaboration if theres interest,
I'll have to figure out how to do that though..
Of course you can clone and fork it.
Its probably premature to concentrate on rework for inclusion,
I think itd be better to get it working on mainline 1st,
but the long view might inform the short-term steps.
thanks
Jim Cromie
^ permalink raw reply
* Re: [PATCH V3 0/6] net/mlx4_en: DCB QoS support
From: Or Gerlitz @ 2012-03-28 22:21 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Roland Dreier, Yevgeny Petrilin, Oren Duer, Amir Vadai,
John Fastabend, Eric Dumazet, Amir Vadai
In-Reply-To: <1332860951-23042-1-git-send-email-amirv@mellanox.com>
On Tue, Mar 27, 2012 at 5:09 PM, Amir Vadai <amirv@mellanox.com> wrote:
> DCBX version 802.1qaz is supported.
> User Priority (UP) is set in QP context instead of in WQE (QP Work Queue
> Element), which means that all traffic from a queue will have the same UP.
> UP is also set for untagged traffic to be able to classify such traffic too.
>
> Mapping from sk_prio to User Priority is done by sch_mqprio mapping. Although
> confusingly sch_mqprio maps sk_prio to something called TC, it is not related
> to DCBX's TC, and is interpreted by mlx4_en driver as UP.
Hi Dave,
Haven't seen a comment from you on this patch set, just wanted to
double check some points are clarified: as was raised in the internal
review, from V0 Amir pointed out on the ratelimit patch (doesn't fit
into the current DCBNL framework) and on the queue selection patch
(changes the spirit of the HW QoS work from Jonh) that they might need
changes - but we preferred to come up with code and not only
theoretic suggestions.
For the ratelimit Eric D. provided feedback and it was implemented
along his suggestion,
and now John and Ben have other suggestions, so need clear feedback
here not to implement this in 2-3 different ways, and this is the
easier piece. As for the HW QoS, the discussion continues.
V3 has patches 1-6 on which no objecting comment was provided, and
they should be okay for merging, unless you see things which need to
change there?
Or.
^ permalink raw reply
* [patch 1/1] net/netfilter/nfnetlink_acct.c: use linux/atomic.h
From: akpm @ 2012-03-28 22:10 UTC (permalink / raw)
To: davem; +Cc: netfilter-devel, netdev, akpm, kaber, pablo
From: Andrew Morton <akpm@linux-foundation.org>
Subject: net/netfilter/nfnetlink_acct.c: use linux/atomic.h
There's no known problem here, but this is one of only two non-arch files
in the kernel which use asm/atomic.h instead of linux/atomic.h.
Acked-by: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Patrick McHardy <kaber@trash.net>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
net/netfilter/nfnetlink_acct.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN net/netfilter/nfnetlink_acct.c~net-netfilter-nfnetlink_acctc-use-linux-atomich net/netfilter/nfnetlink_acct.c
--- a/net/netfilter/nfnetlink_acct.c~net-netfilter-nfnetlink_acctc-use-linux-atomich
+++ a/net/netfilter/nfnetlink_acct.c
@@ -10,6 +10,7 @@
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/skbuff.h>
+#include <linux/atomic.h>
#include <linux/netlink.h>
#include <linux/rculist.h>
#include <linux/slab.h>
@@ -17,7 +18,6 @@
#include <linux/errno.h>
#include <net/netlink.h>
#include <net/sock.h>
-#include <asm/atomic.h>
#include <linux/netfilter.h>
#include <linux/netfilter/nfnetlink.h>
_
^ permalink raw reply
* Re: suspicious RCU usage warnings in 3.3.0
From: David Miller @ 2012-03-28 21:45 UTC (permalink / raw)
To: mroos; +Cc: linux-kernel, netdev
In-Reply-To: <alpine.SOC.1.00.1203281134090.13691@math.ut.ee>
From: Meelis Roos <mroos@linux.ee>
Date: Wed, 28 Mar 2012 11:45:48 +0300 (EEST)
> Is this the same RCU problem that was fixed after 3.3 (fix a potential
> rcu_read_lock() imbalance in rt6_fill_node())? My problem does not seem
> to be ipv6-only, most traces are from IPv6 but some for ip.
It's hard to say because the ipv6 RCU problem causes the warning to
trigger somewhere away from the ipv6 code that had the RCU locking
bug.
We essentially return back into userspace with the RCU lock held, so
the next time we go into the kernel for that thread and do RCU locking
is when we'll notice the problem.
^ permalink raw reply
* Re: [REGRESSION][PATCH] bpf_jit drops the ball on indirect negative mem references
From: David Miller @ 2012-03-28 20:58 UTC (permalink / raw)
To: kaffeemonster; +Cc: netdev, linux-kernel, matt, eric.dumazet
In-Reply-To: <CAPwCz79wO=5zTZmCG+ePfRuEu-p_Vosi18bYZ-MVNZGOdbE3aQ@mail.gmail.com>
Please do not post patches as octet-stream attachments, post them
inline so that:
1) People can more easily review and quote the code in replies.
2) It actually gets logged properly in patchwork.
Otherwise I can guarentee your patch will get less attention than
you would like.
Thanks.
^ permalink raw reply
* Re: [PATCH 1/1] net/hyperv: Add flow control based on hi/low watermark
From: David Miller @ 2012-03-28 20:54 UTC (permalink / raw)
To: bhutchings; +Cc: gregkh, haiyangz, netdev, devel, olaf, linux-kernel
In-Reply-To: <1332957900.2624.38.camel@bwh-desktop.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Wed, 28 Mar 2012 19:05:00 +0100
> On Mon, 2012-03-26 at 19:12 -0400, David Miller wrote:
>> From: Greg KH <gregkh@linuxfoundation.org>
>> Date: Mon, 26 Mar 2012 16:10:17 -0700
>>
>> > David, please do NOT apply this as-is.
>>
>> BTW, ethtool had controls exactly for stuff like this.
>
> Not sure what you're thinking of...? We have pause frame control but I
> don't think that's applicable.
As I understand this, this situation is really about interrupt flow
control, and for that we have the interrupt moderation ethtool
settings.
^ permalink raw reply
* Re: [PATCH] net: reference the ipv4 sysctl table header
From: David Miller @ 2012-03-28 20:51 UTC (permalink / raw)
To: rostedt; +Cc: tixxdz, ebiederm, viro, netdev
In-Reply-To: <20120328163219.GA19778@home.goodmis.org>
From: Steven Rostedt <rostedt@goodmis.org>
Date: Wed, 28 Mar 2012 12:32:20 -0400
> I just started using kmemleak and notice that it reports false positives
> for several __init functions that call register_sysctl_paths(). The fix
> you want is:
>
> {
> sturct ctl_table_header *head;
>
> head = register_sysctl_paths(ipv4_path, ipv4_skeleton);
> BUG_ON(!head);
> kmemleak_ignore(head);
>
>
> No need to waste a pointer just to keep the reference around for
> kmemleak.
That looks a lot saner than the other suggestions, indeed.
^ permalink raw reply
* Re: [PATCH v2] net/garp: avoid infinite loop if attribute already exists
From: David Miller @ 2012-03-28 20:45 UTC (permalink / raw)
To: david.ward; +Cc: jorge, netdev, kaber
In-Reply-To: <4F731212.1090203@ll.mit.edu>
From: "Ward, David - 0663 - MITLL" <david.ward@ll.mit.edu>
Date: Wed, 28 Mar 2012 09:28:50 -0400
> Please add to commit message:
>
> Thanks to Jorge Boncompte [DTI2] <jorge@dti2.net> for contributing to
> this fix.
It's already committed to my tree and therefore in the permanent
record and therefore the message cannot be changed.
Be more careful in the future.
^ permalink raw reply
* Re: [REGRESSION][PATCH] bpf_jit drops the ball on indirect negative mem references
From: Eric Dumazet @ 2012-03-28 20:39 UTC (permalink / raw)
To: Jan Seiffert; +Cc: netdev, linux-kernel, David S. Miller, Matt Evans
In-Reply-To: <CAPwCz7_tnjq32duJSDj21LpRe5TFvGGszH4joQr1DGTjNd7GcA@mail.gmail.com>
On Wed, 2012-03-28 at 22:26 +0200, Jan Seiffert wrote:
> 2012/3/28 Eric Dumazet <eric.dumazet@gmail.com>:
> > On Wed, 2012-03-28 at 21:15 +0200, Jan Seiffert wrote:
> >> Consider the following test program:
> >>
> >> #include <stdio.h>
> >> #include <sys/types.h>
> >> #include <sys/socket.h>
> >> #include <netinet/in.h>
> >> #include <pcap-bpf.h>
> >>
> >> #define die(x) do {perror(x); return 1;} while (0)
> >> struct bpf_insn udp_filter[] = {
> >> /* 0 */ BPF_STMT(BPF_LDX|BPF_W|BPF_IMM, -1048576+(0)), /* leax net[0] */
> >> /* 1 */ BPF_STMT(BPF_LD|BPF_B|BPF_IND, 0), /* ldb [x+0] */
> >> /* 2 */ BPF_STMT(BPF_RET|BPF_A, 0), /* ret a */
> >> };
> >
> > When this point was raised some weeks ago, we wanted to see a _real_ use
> > of negative mem reference.
> >
> > You provide a test program but what this filter is supposed to do
> > exactly ?
> >
>
> Say you have a UDP socket, and you want to filter for bogus source
> addresses (drop already in kernel to save the context switch).
> To have only one bpf program for ipv4 and ipv6 (you have to checked
> the same bogus v4 addresses in mapped space), there is a point where
> it elegant to have a negative offset saved in the X register.
Cool, thats a valid use, thanks.
Problem is you slow down the jit in its normal use, for a very specific
use.
Please rework your patch so that absolute loads of positive offsets
(known at compile time) dont have to test negative offsets at run time.
You add two instructions per load, and thats not good.
Something like :
sk_load_word:
.globl sk_load_word
test %esi,%esi
js bpf_slow_path_word_neg
sk_load_word_positive_offset:
.globl sk_load_word_positive_offset
mov %r9d,%eax # hlen
sub %esi,%eax # hlen - offset
cmp $3,%eax
...
^ 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