From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Horman Subject: Re: [slab poison overwritten] Re: [GIT] Networking Date: Tue, 22 Mar 2011 09:01:33 +0900 Message-ID: <20110322000130.GC27019@verge.net.au> References: <20110320.195156.226769634.davem@davemloft.net> <20110321125320.GA23490@elte.hu> <1300714346.2884.284.camel@edumazet-laptop> <20110321161528.GA28580@elte.hu> <20110321164238.GA5303@elte.hu> <20110321173941.GB3892@elte.hu> <1300730838.2884.578.camel@edumazet-laptop> <1300738540.2837.5.camel@edumazet-laptop> <20110321221357.GF22625@verge.net.au> <20110321232921.GG22625@verge.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Ingo Molnar , David Miller , torvalds@linux-foundation.org, akpm@linux-foundation.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Peter Zijlstra , Thomas Gleixner , Arnd Bergmann , Pekka Enberg , Julian Anastasov , Hans Schillstrom To: Eric Dumazet Return-path: Received: from kirsty.vergenet.net ([202.4.237.240]:57873 "EHLO kirsty.vergenet.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754986Ab1CVABj (ORCPT ); Mon, 21 Mar 2011 20:01:39 -0400 Content-Disposition: inline In-Reply-To: <20110321232921.GG22625@verge.net.au> Sender: netdev-owner@vger.kernel.org List-ID: 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 =C3=A0 19:07 +0100, Eric Dumazet a =C3=A9cr= it : > > > > Le lundi 21 mars 2011 =C3=A0 18:39 +0100, Ingo Molnar a =C3=A9c= rit : > > > > > here's the same but with kallsyms enabled. > > > > >=20 > > > > > Thanks, > > > > >=20 > > > > > Ingo > > > > >=20 > > > > > [ 9.585627] initcall 0xffffffff81d5b806 returned 0 after 0= usecs > > > > > [ 9.588960] calling 0xffffffff81d5b9da @ 1 > > > > > [ 9.592303] IPVS: Creating netns size=3D1272 id=3D0 > > > > > [ 9.595646] IPVS: __ip_vs_control_init(): alloc_percpu. > > > > > [ 9.602298] IPVS: cannot register namespace. > > > > > [ 9.605627] IPVS: can't setup control > > > >=20 > > > > It seems IPVS is busted in case of memory allocation error in=20 > > > > __ip_vs_control_init() > > > >=20 > > > > IPVS deinits its "struct netns_ipvs" space, but something (in I= PVS) uses > > > > it after free. > > > >=20 > > > > __ip_vs_init() seems to be called before ip_vs_init() completes > > > > correctly. We then keep in net->ipvs a pointer to some freed me= mory. > > > >=20 > > > > Commit 14e405461e664b7 did some changes in this area > > > >=20 > > > > Simon, any idea ? > > > >=20 > > > >=20 > > >=20 > > > For the time being, we can avoid the false memory allocation erro= r (and > > > leak) > >=20 > > Sorry, that typo is my work. >=20 > With your patch applied I now see the following >=20 > ffff880003bbf1a0 corresponds to &ipvs->app_key in __ip_vs_app_init(). > I'll continue looking into this. >=20 > [ 12.610000] IPVS: Creating netns size=3D2456 id=3D0 > [ 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] [] warn_slowpath_common+0x75/0xb0 > [ 12.650000] [] warn_slowpath_null+0x15/0x20 > [ 12.650000] [] lockdep_init_map+0x37b/0x570 > [ 12.650000] [] ? trace_hardirqs_on+0xd/0x10 > [ 12.650000] [] debug_mutex_init+0x38/0x50 > [ 12.650000] [] __mutex_init+0x5c/0x70 > [ 12.650000] [] __ip_vs_app_init+0x64/0x86 > [ 12.660000] [] ? ip_vs_init+0x0/0xff > [ 12.660000] [] T.620+0x43/0x170 > [ 12.660000] [] ? register_pernet_subsys+0x1a/0x= 40 > [ 12.660000] [] ? ip_vs_init+0x0/0xff > [ 12.660000] [] ? ip_vs_init+0x0/0xff > [ 12.660000] [] register_pernet_operations+0x57/= 0xb0 > [ 12.660000] [] ? ip_vs_init+0x0/0xff > [ 12.670000] [] register_pernet_subsys+0x29/0x40 > [ 12.670000] [] ip_vs_app_init+0x10/0x12 > [ 12.670000] [] ip_vs_init+0x4c/0xff > [ 12.670000] [] do_one_initcall+0x7a/0x12e > [ 12.670000] [] kernel_init+0x13e/0x1c2 > [ 12.670000] [] kernel_thread_helper+0x4/0x10 > [ 12.670000] [] ? restore_args+0x0/0x30 > [ 12.680000] [] ? kernel_init+0x0/0x1c2 > [ 12.680000] [] ? 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); =20 -/* 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= =3D { =20 static int __net_init __ip_vs_app_init(struct net *net) { + struct netns_ipvs *ipvs =3D net_ipvs(net); + if (!net_eq(net, &init_net)) /* netns not enabled yet */ return -EPERM; =20 + 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; }