On Thursday, June 09, 2011 15:11:23 Patrick McHardy wrote: > On 09.06.2011 14:57, Hans Schillstrom wrote: > > Hello > > I have a problem with ip_vs_conn_flush() and expiring timers ... > > After a couple of hours checking locks, I'm still not closer to a solution > > Conntrack differs a bit between 2.6.32 vs .2.6.39 but I don't think that's the reason in this case. > > > > I think the netns cleanup cased this, but I'm not a conntrack expert :) > > > > The dump below is from a back-ported ipvs to 2.6.32.27 > > The extra patches that renamed the cleanup patches is there that I sent to Simon i.e > > __ip_vs_conn_cleanup renamed to ip_vs_conn_net_cleanup etc. > > > > > > [ 532.287410] CPU 3 > > [ 532.287410] Modules linked in: xt_mark xt_conntrack ip_vs_wrr(N) ip_vs_lc(N) xt_tcpudp ip_vs_rr(N) nf_conntrack_ipv6 xt_MARK xt_state xt_CONNMARK xt_connmark xt_multiport nf_conntrack_netlink nfnetlink xt_hmark(N) ip6table_mangle iptable_mangle ip6table_filter iptable_filter ip6_tables ip_tables x_tables nf_conntrack_ipv4 nf_defrag_ipv4 ip_vs(N) nf_conntrack ip6_tunnel tunnel6 tipc(N) nfs fscache af_packet nfsd lockd nfs_acl auth_rpcgss sunrpc exportfs drbd softdog bonding macvlan ipv6 ext3 jbd mbcache loop dm_mod usbhid hid ide_pci_generic piix ide_core ata_generic ata_piix ahci libata hpsa uhci_hcd hpilo xen_platform_pci cdrom pcspkr ehci_hcd cciss tpm_tis tpm tpm_bios bnx2 serio_raw ipmi_si ipmi_msghandler i5k_amb i5000_edac rtc_cmos rtc_core rtc_lib usbcore container e1000e edac_core shpchp pci_hotplug scsi_mod button thermal processor thermal_sys hwmon > > [ 532.350212] Supported: Yes > > [ 532.350212] Pid: 17, comm: netns Tainted: G N 2.6.32.27-0.2.2.2501.1.PTF-evip #1 ProLiant DL380 G5 > > [ 532.386359] RIP: 0010:[<ffffffff8131aaf6>] [<ffffffff8131aaf6>] netlink_has_listeners+0x36/0x40 > > [ 532.386359] RSP: 0018:ffff880005ac3bf0 EFLAGS: 00010246 > > [ 532.386359] RAX: 0000000000000002 RBX: ffff8800345e2ea8 RCX: ffff880005ac3c98 > > [ 532.386359] RDX: ffff88012380d740 RSI: 0000000000000003 RDI: ffff88012819a400 > > [ 532.386359] RBP: ffff880005ac3d28 R08: ffffffffa0641ca8 R09: 0000000000000024 > > [ 532.386359] R10: 0000000000004000 R11: 0000000000000000 R12: ffff8800345e2ea8 > > [ 532.386359] R13: 0000000000000002 R14: 0000000000000004 R15: ffff88012a875fd8 > > [ 532.386359] FS: 0000000000000000(0000) GS:ffff880005ac0000(0000) knlGS:0000000000000000 > > [ 532.386359] CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b > > [ 532.386359] CR2: 00007f6a0ecba000 CR3: 0000000001804000 CR4: 00000000000406e0 > > [ 532.386359] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > > [ 532.386359] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > > [ 532.386359] Process netns (pid: 17, threadinfo ffff88012a874000, task ffff88012a872500) > > [ 532.485087] Stack: > > [ 532.485087] ffffffffa063ff92 ffffffff811e2805 ffff880005ac3c98 00000004811e2805 > > [ 532.485087] <0> ffff88011d9bd500 0000000300000000 ffff880005ac3da0 ffffffff8103e402 > > [ 532.485087] <0> ffff880005ac3d40 ffff880005ac3cb0 0000000000013700 0000000000000010 > > [ 532.485087] Call Trace: > > [ 532.485087] [<ffffffffa063ff92>] ctnetlink_conntrack_event+0x92/0x730 [nf_conntrack_netlink] > > [ 532.485087] [<ffffffffa058b274>] death_by_timeout+0xc4/0x190 [nf_conntrack] ## ct->timeout.function(ct->timeout.data); ## > > [ 532.485087] [<ffffffffa05c544d>] ip_vs_conn_drop_conntrack+0x13d/0x360 [ip_vs] > > [ 532.485087] [<ffffffffa05ae30d>] ip_vs_conn_expire+0x12d/0x7d0 [ip_vs] ## expired timer ## > > [ 532.485087] [<ffffffff81059424>] run_timer_softirq+0x174/0x240 > > [ 532.549596] [<ffffffff810544ef>] __do_softirq+0xbf/0x170 > > [ 532.549596] [<ffffffff810040bc>] call_softirq+0x1c/0x30 > > [ 532.549596] [<ffffffff81005d1d>] do_softirq+0x4d/0x80 > > [ 532.549596] [<ffffffff81054791>] local_bh_enable_ip+0xa1/0xb0 ## ct_write_unlock_bh(idx); ## > > [ 532.549596] [<ffffffffa05ac25b>] ip_vs_conn_net_cleanup+0xdb/0x160 [ip_vs] ## ip_vs_flush in-lined ## > > [ 532.576259] [<ffffffffa05afae1>] __ip_vs_cleanup+0x11/0x90 [ip_vs] > > [ 532.576259] [<ffffffff812f840e>] cleanup_net+0x5e/0xb0 > > [ 532.576259] [<ffffffff81061468>] run_workqueue+0xb8/0x140 > > [ 532.594226] [<ffffffff8106158a>] worker_thread+0x9a/0x110 > > [ 532.594226] [<ffffffff81065696>] kthread+0x96/0xb0 > > [ 532.603788] [<ffffffff81003fba>] child_rip+0xa/0x20 > > [ 532.603788] Code: 47 41 8d 4e ff 48 8d 14 80 48 8d 14 50 31 c0 48 c1 e2 03 48 03 15 7b b2 9b 00 3b 4a 3c 48 8b 7a 30 72 02 f3 c3 0f a3 0f 19 c0 c3 <0f> 0b eb fe 66 0f 1f 44 00 00 48 81 ec 98 00 00 00 41 f6 c0 01 > > [ 532.623046] RIP [<ffffffff8131aaf6>] netlink_has_listeners+0x36/0x40 > > This looks like nfnetlink.c excited and destroyed the nfnl socket, but > ip_vs was still holding a reference to a conntrack. When the conntrack > got destroyed it created a ctnetlink event, causing an oops in > netlink_has_listeners when trying to use the destroyed nfnetlink > socket. > > Usually this shouldn't happen since network namespace cleanup > happens in reverse order from registration. In this case the > reason might be that IPVS has no dependencies on conntrack > or ctnetlink and therefore can get loaded first, meaning it > will get cleaned up afterwards. > > Does that make any sense? > Yes, >From what I can see is ip_vs have a dependency on nf_conntrack but not on nf_conntrack_netlink i.e. nf_conntrack is loded first and then ip_vs and last nf_conntrack_netlink It's hard to tell exactly what was going on in user-space when the lxc container get killed.... Basically there is a lot of traffic (and connections) through the container with ipvs inside, - ipvs conntrack support is turned on - iptables with conntrack - conntrackd is running - ~50 iptables rules I'm not sure if it's only IPv4 traffic ... Hmmm... I think I know, the culprit is conntrackd !! (i.e. it causes loading of ct_netlink) conntrackd will definitely get killed before the namespace exit starts I think it is like you describe, I will make some test tomorrow. How to solve this is another question.... Thanks a lot Patrick. Regards Hans Schillstrom -- To unsubscribe from this list: send the line "unsubscribe lvs-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
