* BUG nf_conntrack_ffff880863c50000: Objects remaining on kmem_cache_close() @ 2012-02-08 14:45 Jean-Philippe Menil 2012-02-09 15:57 ` Pablo Neira Ayuso 0 siblings, 1 reply; 8+ messages in thread From: Jean-Philippe Menil @ 2012-02-08 14:45 UTC (permalink / raw) To: netfilter-devel [-- Attachment #1: Type: text/plain, Size: 474 bytes --] Hi, I'm seeing bug in a host with a 3.2.1 kernel. This host is running both kvm and lxc guest. It seems that it happened just after the restart of a lxc guest. However, it doesn't seem to affect any guest. I was just wondering if this was problematic, and if so, what should I do to debug this further. Regards. -- Jean-Philippe Menil - Pôle réseau Service IRTS DSI Université de Nantes jean-philippe.menil@univ-nantes.fr Tel : 02.53.48.49.27 - Fax : 02.53.48.49.09 [-- Attachment #2: bug.txt --] [-- Type: text/plain, Size: 4763 bytes --] Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.285125] ============================================================================= Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.285173] BUG nf_conntrack_ffff880863c50000: Objects remaining on kmem_cache_close() Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.285223] ----------------------------------------------------------------------------- Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.285224] Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.285291] INFO: Slab 0xffffea000fecf280 objects=26 used=1 fp=0xffff8803fb3ca4e0 flags=0x200000000004080 Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.285339] Pid: 5, comm: kworker/u:0 Not tainted 3.2.1-dsiun-120113 #55 Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.285366] Call Trace: Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.285393] [<ffffffff811194c0>] ? slab_err+0x80/0x90 Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.285419] [<ffffffff8111c6c9>] ? kmem_cache_destroy+0x169/0x3b0 Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.285449] [<ffffffff8111c6ec>] ? kmem_cache_destroy+0x18c/0x3b0 Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.285487] [<ffffffffa049f753>] ? nf_conntrack_cleanup+0xd3/0x130 [nf_conntrack] Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.285545] [<ffffffff812f7b48>] ? ops_exit_list.isra.1+0x38/0x70 Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.285574] [<ffffffff812f8260>] ? net_drop_ns+0x40/0x40 Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.285600] [<ffffffff812f8360>] ? cleanup_net+0x100/0x1a0 Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.285643] [<ffffffff810635c6>] ? process_one_work+0x106/0x460 Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.285670] [<ffffffff8106486c>] ? worker_thread+0x14c/0x330 Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.285697] [<ffffffff81064720>] ? manage_workers.isra.30+0x210/0x210 Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.285736] [<ffffffff8106905e>] ? kthread+0x7e/0x90 Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.285763] [<ffffffff813aee34>] ? kernel_thread_helper+0x4/0x10 Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.285790] [<ffffffff81068fe0>] ? kthread_worker_fn+0x190/0x190 Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.285817] [<ffffffff813aee30>] ? gs_change+0x13/0x13 Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.285843] INFO: Object 0xffff8803fb3ca000 @offset=0 Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.285869] SLUB nf_conntrack_ffff880863c50000: kmem_cache_destroy called for cache that still has objects. Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.285916] Pid: 5, comm: kworker/u:0 Not tainted 3.2.1-dsiun-120113 #55 Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.285943] Call Trace: Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.285964] [<ffffffff8111c7a8>] ? kmem_cache_destroy+0x248/0x3b0 Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.285991] [<ffffffff8111c863>] ? kmem_cache_destroy+0x303/0x3b0 Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.286020] [<ffffffffa049f753>] ? nf_conntrack_cleanup+0xd3/0x130 [nf_conntrack] Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.286064] [<ffffffff812f7b48>] ? ops_exit_list.isra.1+0x38/0x70 Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.286092] [<ffffffff812f8260>] ? net_drop_ns+0x40/0x40 Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.286117] [<ffffffff812f8360>] ? cleanup_net+0x100/0x1a0 Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.286144] [<ffffffff810635c6>] ? process_one_work+0x106/0x460 Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.286227] [<ffffffff8106486c>] ? worker_thread+0x14c/0x330 Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.286253] [<ffffffff81064720>] ? manage_workers.isra.30+0x210/0x210 Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.286281] [<ffffffff8106905e>] ? kthread+0x7e/0x90 Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.286306] [<ffffffff813aee34>] ? kernel_thread_helper+0x4/0x10 Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.286333] [<ffffffff81068fe0>] ? kthread_worker_fn+0x190/0x190 Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.286360] [<ffffffff813aee30>] ? gs_change+0x13/0x13 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: BUG nf_conntrack_ffff880863c50000: Objects remaining on kmem_cache_close() 2012-02-08 14:45 BUG nf_conntrack_ffff880863c50000: Objects remaining on kmem_cache_close() Jean-Philippe Menil @ 2012-02-09 15:57 ` Pablo Neira Ayuso 2012-02-09 16:11 ` Jean-Philippe Menil 0 siblings, 1 reply; 8+ messages in thread From: Pablo Neira Ayuso @ 2012-02-09 15:57 UTC (permalink / raw) To: Jean-Philippe Menil; +Cc: netfilter-devel On Wed, Feb 08, 2012 at 03:45:21PM +0100, Jean-Philippe Menil wrote: > Hi, > > I'm seeing bug in a host with a 3.2.1 kernel. > This host is running both kvm and lxc guest. > It seems that it happened just after the restart of a lxc guest. > > However, it doesn't seem to affect any guest. > > I was just wondering if this was problematic, and if so, what should > I do to debug this further. Could you provide more information on your setup? Is it using conntrackd or anything you think it can be relevant to this bug. It can make it easier for us to know what's wrong with this. > Regards. > > -- > Jean-Philippe Menil - Pôle réseau Service IRTS > DSI Université de Nantes > jean-philippe.menil@univ-nantes.fr > Tel : 02.53.48.49.27 - Fax : 02.53.48.49.09 > > Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.285125] ============================================================================= > Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.285173] BUG nf_conntrack_ffff880863c50000: Objects remaining on kmem_cache_close() > Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.285223] ----------------------------------------------------------------------------- > Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.285224] > Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.285291] INFO: Slab 0xffffea000fecf280 objects=26 used=1 fp=0xffff8803fb3ca4e0 flags=0x200000000004080 > Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.285339] Pid: 5, comm: kworker/u:0 Not tainted 3.2.1-dsiun-120113 #55 > Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.285366] Call Trace: > Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.285393] [<ffffffff811194c0>] ? slab_err+0x80/0x90 > Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.285419] [<ffffffff8111c6c9>] ? kmem_cache_destroy+0x169/0x3b0 > Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.285449] [<ffffffff8111c6ec>] ? kmem_cache_destroy+0x18c/0x3b0 > Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.285487] [<ffffffffa049f753>] ? nf_conntrack_cleanup+0xd3/0x130 [nf_conntrack] > Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.285545] [<ffffffff812f7b48>] ? ops_exit_list.isra.1+0x38/0x70 > Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.285574] [<ffffffff812f8260>] ? net_drop_ns+0x40/0x40 > Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.285600] [<ffffffff812f8360>] ? cleanup_net+0x100/0x1a0 > Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.285643] [<ffffffff810635c6>] ? process_one_work+0x106/0x460 > Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.285670] [<ffffffff8106486c>] ? worker_thread+0x14c/0x330 > Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.285697] [<ffffffff81064720>] ? manage_workers.isra.30+0x210/0x210 > Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.285736] [<ffffffff8106905e>] ? kthread+0x7e/0x90 > Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.285763] [<ffffffff813aee34>] ? kernel_thread_helper+0x4/0x10 > Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.285790] [<ffffffff81068fe0>] ? kthread_worker_fn+0x190/0x190 > Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.285817] [<ffffffff813aee30>] ? gs_change+0x13/0x13 > Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.285843] INFO: Object 0xffff8803fb3ca000 @offset=0 > Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.285869] SLUB nf_conntrack_ffff880863c50000: kmem_cache_destroy called for cache that still has objects. > Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.285916] Pid: 5, comm: kworker/u:0 Not tainted 3.2.1-dsiun-120113 #55 > Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.285943] Call Trace: > Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.285964] [<ffffffff8111c7a8>] ? kmem_cache_destroy+0x248/0x3b0 > Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.285991] [<ffffffff8111c863>] ? kmem_cache_destroy+0x303/0x3b0 > Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.286020] [<ffffffffa049f753>] ? nf_conntrack_cleanup+0xd3/0x130 [nf_conntrack] > Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.286064] [<ffffffff812f7b48>] ? ops_exit_list.isra.1+0x38/0x70 > Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.286092] [<ffffffff812f8260>] ? net_drop_ns+0x40/0x40 > Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.286117] [<ffffffff812f8360>] ? cleanup_net+0x100/0x1a0 > Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.286144] [<ffffffff810635c6>] ? process_one_work+0x106/0x460 > Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.286227] [<ffffffff8106486c>] ? worker_thread+0x14c/0x330 > Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.286253] [<ffffffff81064720>] ? manage_workers.isra.30+0x210/0x210 > Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.286281] [<ffffffff8106905e>] ? kthread+0x7e/0x90 > Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.286306] [<ffffffff813aee34>] ? kernel_thread_helper+0x4/0x10 > Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.286333] [<ffffffff81068fe0>] ? kthread_worker_fn+0x190/0x190 > Feb 8 13:31:38 ayrshire.u06.univ-nantes.prive kernel: [1133137.286360] [<ffffffff813aee30>] ? gs_change+0x13/0x13 > > -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: BUG nf_conntrack_ffff880863c50000: Objects remaining on kmem_cache_close() 2012-02-09 15:57 ` Pablo Neira Ayuso @ 2012-02-09 16:11 ` Jean-Philippe Menil 2012-02-09 19:39 ` Pablo Neira Ayuso 0 siblings, 1 reply; 8+ messages in thread From: Jean-Philippe Menil @ 2012-02-09 16:11 UTC (permalink / raw) To: Pablo Neira Ayuso; +Cc: netfilter-devel [-- Attachment #1: Type: text/plain, Size: 1384 bytes --] Le 09/02/2012 16:57, Pablo Neira Ayuso a écrit : > On Wed, Feb 08, 2012 at 03:45:21PM +0100, Jean-Philippe Menil wrote: >> Hi, >> >> I'm seeing bug in a host with a 3.2.1 kernel. >> This host is running both kvm and lxc guest. >> It seems that it happened just after the restart of a lxc guest. >> >> However, it doesn't seem to affect any guest. >> >> I was just wondering if this was problematic, and if so, what should >> I do to debug this further. > Could you provide more information on your setup? Is it using > conntrackd or anything you think it can be relevant to this bug. > > It can make it easier for us to know what's wrong with this. > Hi, the server hosts two kvm guest (one firewall running contrackd, one captive portal) and a lxc guest (running squid). This setup remain unchanged for month, except the kernel (reboot with a 3.2.1 one week ago). Attached rules are applied on the host. For the lxc guest, filtering is done on the host, for the two kvm, filtering is done inside. For information, the firewall is in passive mode. As this bug appears only one time, just after restart the lxc guest, i think it's related to containers. But it semmes to be a non-blocking bug. Hope this help. Regards -- Jean-Philippe Menil - Pôle réseau Service IRTS DSI Université de Nantes jean-philippe.menil@univ-nantes.fr Tel : 02.53.48.49.27 - Fax : 02.53.48.49.09 [-- Attachment #2: rules --] [-- Type: text/plain, Size: 8576 bytes --] # Generated by iptables-save v1.4.8 on Thu Feb 9 17:07:09 2012 *filter :INPUT DROP [10417510:1703902887] :FORWARD DROP [0:0] :OUTPUT DROP [5:300] :GENERAL-IN - [0:0] :GENERAL-OUT - [0:0] :GUEST-IN - [0:0] :GUEST-IN_cache2-crous - [0:0] :GUEST-IN_cache2-crous_LO - [0:0] :GUEST-OUT - [0:0] :GUEST-OUT_cache2-crous - [0:0] :GUEST-OUT_cache2-crous_LO - [0:0] :LOCAL-IN - [0:0] :LOCAL-OUT - [0:0] -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -j GENERAL-IN -A INPUT -j LOCAL-IN -A INPUT -m limit --limit 20/sec --limit-burst 30 -j LOG --log-prefix "INPUT ayrshire " --log-level 7 -A FORWARD -m physdev --physdev-out fwcnec -j ACCEPT -A FORWARD -m physdev --physdev-in fwcnec -j ACCEPT -A FORWARD -m physdev --physdev-out fwcnec-ren -j ACCEPT -A FORWARD -m physdev --physdev-in fwcnec-ren -j ACCEPT -A FORWARD -m physdev --physdev-out pcrous-v2037 -j ACCEPT -A FORWARD -m physdev --physdev-in pcrous-v2037 -j ACCEPT -A FORWARD -m physdev --physdev-out pcrous-v2036 -j ACCEPT -A FORWARD -m physdev --physdev-in pcrous-v2036 -j ACCEPT -A FORWARD -m physdev --physdev-out pcrous-v2035 -j ACCEPT -A FORWARD -m physdev --physdev-in pcrous-v2035 -j ACCEPT -A FORWARD -m physdev --physdev-out pcrous-v2033 -j ACCEPT -A FORWARD -m physdev --physdev-in pcrous-v2033 -j ACCEPT -A FORWARD -m physdev --physdev-out pcrous-v2032 -j ACCEPT -A FORWARD -m physdev --physdev-in pcrous-v2032 -j ACCEPT -A FORWARD -m physdev --physdev-out pcrous-v2031 -j ACCEPT -A FORWARD -m physdev --physdev-in pcrous-v2031 -j ACCEPT -A FORWARD -m physdev --physdev-out pcrous-v2030 -j ACCEPT -A FORWARD -m physdev --physdev-in pcrous-v2030 -j ACCEPT -A FORWARD -m physdev --physdev-out pcrous-v197 -j ACCEPT -A FORWARD -m physdev --physdev-in pcrous-v197 -j ACCEPT -A FORWARD -m physdev --physdev-out pcrous-v196 -j ACCEPT -A FORWARD -m physdev --physdev-in pcrous-v196 -j ACCEPT -A FORWARD -m physdev --physdev-out pcrous-v195 -j ACCEPT -A FORWARD -m physdev --physdev-in pcrous-v195 -j ACCEPT -A FORWARD -m physdev --physdev-out pcrous-v194 -j ACCEPT -A FORWARD -m physdev --physdev-in pcrous-v194 -j ACCEPT -A FORWARD -m physdev --physdev-out pcrous-v193 -j ACCEPT -A FORWARD -m physdev --physdev-in pcrous-v193 -j ACCEPT -A FORWARD -m physdev --physdev-out pcrous-v192 -j ACCEPT -A FORWARD -m physdev --physdev-in pcrous-v192 -j ACCEPT -A FORWARD -m physdev --physdev-out pcrous-dmz -j ACCEPT -A FORWARD -m physdev --physdev-in pcrous-dmz -j ACCEPT -A FORWARD -m physdev --physdev-out fwcite-ren -j ACCEPT -A FORWARD -m physdev --physdev-in fwcite-ren -j ACCEPT -A FORWARD -m physdev --physdev-out fwcite-dmz -j ACCEPT -A FORWARD -m physdev --physdev-in fwcite-dmz -j ACCEPT -A FORWARD -j GUEST-IN -A FORWARD -j GUEST-OUT -A FORWARD -m limit --limit 20/sec --limit-burst 30 -j LOG --log-prefix "FORWARD ayrshire " --log-level 7 -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A OUTPUT -j GENERAL-OUT -A OUTPUT -j LOCAL-OUT -A OUTPUT -m limit --limit 20/sec --limit-burst 30 -j LOG --log-prefix "OUTPUT ayrshire " --log-level 7 -A GENERAL-IN -i lo -j ACCEPT -A GENERAL-IN -s 172.20.13.0/24 -p tcp -m tcp --dport 22 -j ACCEPT -A GENERAL-IN -s 193.52.101.133/32 -p tcp -m tcp --dport 22 -j ACCEPT -A GENERAL-IN -p icmp -m limit --limit 30/sec --limit-burst 30 -j ACCEPT -A GENERAL-IN -p icmp -j DROP -A GENERAL-IN -s 172.20.12.96/32 -p tcp -m tcp --dport 22 -j ACCEPT -A GENERAL-IN -s 172.20.12.35/32 -p udp -m multiport --dports 20030:20070 -j ACCEPT -A GENERAL-IN -s 172.20.12.35/32 -p tcp -m multiport --dports 20030:20070 -j ACCEPT -A GENERAL-IN -s 172.20.11.91/32 -p udp -m multiport --dports 20030:20070 -j ACCEPT -A GENERAL-IN -s 172.20.11.91/32 -p tcp -m multiport --dports 20030:20070 -j ACCEPT -A GENERAL-IN -s 172.20.12.160/32 -p tcp -m tcp --dport 22 -j ACCEPT -A GENERAL-IN -s 172.20.12.135/32 -p tcp -m tcp --dport 5308 -j ACCEPT -A GENERAL-IN -s 172.20.12.116/32 -p udp -m udp --dport 161 -j ACCEPT -A GENERAL-IN -s 172.20.12.71/32 -p udp -m udp --dport 161 -j ACCEPT -A GENERAL-IN -s 172.20.12.14/32 -p udp -m udp --dport 161 -j ACCEPT -A GENERAL-OUT -o lo -j ACCEPT -A GENERAL-OUT -p icmp -m limit --limit 30/sec --limit-burst 30 -j ACCEPT -A GENERAL-OUT -p icmp -j DROP -A GENERAL-OUT -d 172.26.4.20/32 -p udp -m udp --dport 53 -j ACCEPT -A GENERAL-OUT -d 172.26.4.20/32 -p tcp -m tcp --dport 53 -j ACCEPT -A GENERAL-OUT -d 172.20.12.22/32 -p udp -m udp --dport 53 -j ACCEPT -A GENERAL-OUT -d 172.20.12.23/32 -p udp -m udp --dport 53 -j ACCEPT -A GENERAL-OUT -d 172.20.12.11/32 -p udp -m udp --dport 53 -j ACCEPT -A GENERAL-OUT -d 172.20.12.11/32 -p tcp -m tcp --dport 53 -j ACCEPT -A GENERAL-OUT -d 172.20.12.22/32 -p tcp -m tcp --dport 53 -j ACCEPT -A GENERAL-OUT -d 172.20.12.23/32 -p tcp -m tcp --dport 53 -j ACCEPT -A GENERAL-OUT -d 172.20.12.96/32 -p tcp -m tcp --dport 22 -j ACCEPT -A GENERAL-OUT -d 172.20.12.56/32 -p tcp -m tcp --dport 25 -j ACCEPT -A GENERAL-OUT -d 172.20.12.55/32 -p tcp -m tcp --dport 25 -j ACCEPT -A GENERAL-OUT -d 172.20.12.88/32 -p tcp -m tcp --dport 389 -j ACCEPT -A GENERAL-OUT -d 172.20.12.89/32 -p tcp -m tcp --dport 389 -j ACCEPT -A GENERAL-OUT -d 172.20.12.90/32 -p tcp -m tcp --dport 389 -j ACCEPT -A GENERAL-OUT -d 172.20.12.240/32 -p tcp -m tcp --dport 389 -j ACCEPT -A GENERAL-OUT -d 172.20.12.90/32 -p tcp -m tcp --dport 636 -j ACCEPT -A GENERAL-OUT -d 172.20.12.88/32 -p tcp -m tcp --dport 636 -j ACCEPT -A GENERAL-OUT -d 172.20.12.89/32 -p tcp -m tcp --dport 636 -j ACCEPT -A GENERAL-OUT -d 172.20.12.240/32 -p tcp -m tcp --dport 636 -j ACCEPT -A GENERAL-OUT -d 172.20.12.31/32 -p udp -m udp --dport 123 -j ACCEPT -A GENERAL-OUT -d 193.52.101.123/32 -p udp -m udp --dport 123 -j ACCEPT -A GENERAL-OUT -d 172.20.12.35/32 -p udp -m multiport --dports 20030:20070 -j ACCEPT -A GENERAL-OUT -d 172.20.12.35/32 -p tcp -m multiport --dports 20030:20070 -j ACCEPT -A GENERAL-OUT -d 172.20.11.91/32 -p udp -m multiport --dports 20030:20070 -j ACCEPT -A GENERAL-OUT -d 172.20.11.91/32 -p tcp -m multiport --dports 20030:20070 -j ACCEPT -A GENERAL-OUT -d 172.20.12.48/32 -p tcp -m tcp --dport 873 -j ACCEPT -A GENERAL-OUT -d 172.20.12.135/32 -p tcp -m tcp --dport 5308 -j ACCEPT -A GENERAL-OUT -d 172.20.12.34/32 -p tcp -m tcp --dport 21 -j ACCEPT -A GENERAL-OUT -d 172.20.12.74/32 -p tcp -m tcp --dport 3128 -j ACCEPT -A GENERAL-OUT -d 172.20.11.67/32 -p tcp -m tcp --dport 22 -j ACCEPT -A GENERAL-OUT -d 172.20.12.14/32 -p udp -m udp --dport 514 -j ACCEPT -A GUEST-IN -m physdev --physdev-out cache2-crous -j GUEST-IN_cache2-crous -A GUEST-IN_cache2-crous -m state --state RELATED,ESTABLISHED -j ACCEPT -A GUEST-IN_cache2-crous -j GENERAL-IN -A GUEST-IN_cache2-crous -j GUEST-IN_cache2-crous_LO -A GUEST-IN_cache2-crous -m limit --limit 20/sec --limit-burst 30 -j LOG --log-prefix "INBOUND cache2-crous " --log-level 7 -A GUEST-IN_cache2-crous -j DROP -A GUEST-IN_cache2-crous_LO -d 224.0.0.18/32 -p vrrp -j ACCEPT -A GUEST-IN_cache2-crous_LO -d 224.0.0.18/32 -p ah -j ACCEPT -A GUEST-IN_cache2-crous_LO -d 193.52.102.11/32 -p udp -m udp --dport 5001 -j ACCEPT -A GUEST-IN_cache2-crous_LO -d 193.52.102.12/32 -p tcp -m tcp --dport 5001 -j ACCEPT -A GUEST-IN_cache2-crous_LO -d 225.0.0.50/32 -j DROP -A GUEST-IN_cache2-crous_LO -d 224.0.0.111/32 -j DROP -A GUEST-IN_cache2-crous_LO -p tcp -m tcp --dport 3128 -j ACCEPT -A GUEST-IN_cache2-crous_LO -s 172.20.12.116/32 -p tcp -m tcp --dport 22 -j ACCEPT -A GUEST-IN_cache2-crous_LO -s 172.20.12.160/32 -p tcp -m tcp --dport 22 -j ACCEPT -A GUEST-IN_cache2-crous_LO -s 172.20.12.160/32 -p tcp -m tcp --dport 873 -j ACCEPT -A GUEST-OUT -m physdev --physdev-in cache2-crous -j GUEST-OUT_cache2-crous -A GUEST-OUT_cache2-crous -m state --state RELATED,ESTABLISHED -j ACCEPT -A GUEST-OUT_cache2-crous -j GENERAL-OUT -A GUEST-OUT_cache2-crous -j GUEST-OUT_cache2-crous_LO -A GUEST-OUT_cache2-crous -m limit --limit 20/sec --limit-burst 30 -j LOG --log-prefix "OUTBOUND cache2-crous " --log-level 7 -A GUEST-OUT_cache2-crous -j DROP -A GUEST-OUT_cache2-crous_LO -d 224.0.0.18/32 -p vrrp -j ACCEPT -A GUEST-OUT_cache2-crous_LO -d 224.0.0.18/32 -p ah -j ACCEPT -A GUEST-OUT_cache2-crous_LO -p tcp -m tcp --dport 80 -j ACCEPT -A GUEST-OUT_cache2-crous_LO -p tcp -m tcp --dport 443 -j ACCEPT -A GUEST-OUT_cache2-crous_LO -p tcp -m tcp --dport 21 -j ACCEPT -A GUEST-OUT_cache2-crous_LO -d 172.20.12.116/32 -p udp -m udp --dport 162 -j ACCEPT -A LOCAL-IN -s 172.20.13.0/24 -p tcp -m multiport --dports 5900:5999 -j ACCEPT COMMIT # Completed on Thu Feb 9 17:07:09 2012 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: BUG nf_conntrack_ffff880863c50000: Objects remaining on kmem_cache_close() 2012-02-09 16:11 ` Jean-Philippe Menil @ 2012-02-09 19:39 ` Pablo Neira Ayuso 2012-02-10 7:44 ` Jean-Philippe Menil 0 siblings, 1 reply; 8+ messages in thread From: Pablo Neira Ayuso @ 2012-02-09 19:39 UTC (permalink / raw) To: Jean-Philippe Menil; +Cc: netfilter-devel On Thu, Feb 09, 2012 at 05:11:40PM +0100, Jean-Philippe Menil wrote: > Le 09/02/2012 16:57, Pablo Neira Ayuso a écrit : > >On Wed, Feb 08, 2012 at 03:45:21PM +0100, Jean-Philippe Menil wrote: > >>Hi, > >> > >>I'm seeing bug in a host with a 3.2.1 kernel. > >>This host is running both kvm and lxc guest. > >>It seems that it happened just after the restart of a lxc guest. > >> > >>However, it doesn't seem to affect any guest. > >> > >>I was just wondering if this was problematic, and if so, what should > >>I do to debug this further. > >Could you provide more information on your setup? Is it using > >conntrackd or anything you think it can be relevant to this bug. > > > >It can make it easier for us to know what's wrong with this. > > > Hi, > > the server hosts two kvm guest (one firewall running contrackd, one > captive portal) and a lxc guest (running squid). > This setup remain unchanged for month, except the kernel (reboot > with a 3.2.1 one week ago). Is conntrackd running with NetlinkEventsReliable On? -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: BUG nf_conntrack_ffff880863c50000: Objects remaining on kmem_cache_close() 2012-02-09 19:39 ` Pablo Neira Ayuso @ 2012-02-10 7:44 ` Jean-Philippe Menil 2012-02-10 7:54 ` Eric Dumazet 0 siblings, 1 reply; 8+ messages in thread From: Jean-Philippe Menil @ 2012-02-10 7:44 UTC (permalink / raw) To: Pablo Neira Ayuso; +Cc: netfilter-devel Le 09/02/2012 20:39, Pablo Neira Ayuso a écrit : > On Thu, Feb 09, 2012 at 05:11:40PM +0100, Jean-Philippe Menil wrote: >> Le 09/02/2012 16:57, Pablo Neira Ayuso a écrit : >>> On Wed, Feb 08, 2012 at 03:45:21PM +0100, Jean-Philippe Menil wrote: >>>> Hi, >>>> >>>> I'm seeing bug in a host with a 3.2.1 kernel. >>>> This host is running both kvm and lxc guest. >>>> It seems that it happened just after the restart of a lxc guest. >>>> >>>> However, it doesn't seem to affect any guest. >>>> >>>> I was just wondering if this was problematic, and if so, what should >>>> I do to debug this further. >>> Could you provide more information on your setup? Is it using >>> conntrackd or anything you think it can be relevant to this bug. >>> >>> It can make it easier for us to know what's wrong with this. >>> >> Hi, >> >> the server hosts two kvm guest (one firewall running contrackd, one >> captive portal) and a lxc guest (running squid). >> This setup remain unchanged for month, except the kernel (reboot >> with a 3.2.1 one week ago). > Is conntrackd running with NetlinkEventsReliable On? Hi, No, the NetlinkEventsReliable is commented in the configuration file. However, on the same hosts, i see strange things: ths host boot with the following parameter: net.netfilter.nf_conntrack_max=262144 net.netfilter.nf_conntrack_tcp_timeout_established=10800 nf_conntrack is loaded with the following parameter: options nf_conntrack hashsize=262144 But it seems that the nf_conntrack_max reset to his default value (65536) periodically. Three days ago, i manually increase the nf_conntrack_max to 262144, yesterday i see plenty of "nf_conntrack: table full, dropping packet". checking the value, is fall down to 65536. It's maybe not related, but i can't understand how the value can change? Regards. -- Jean-Philippe Menil - Pôle réseau Service IRTS DSI Université de Nantes jean-philippe.menil@univ-nantes.fr Tel : 02.53.48.49.27 - Fax : 02.53.48.49.09 -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: BUG nf_conntrack_ffff880863c50000: Objects remaining on kmem_cache_close() 2012-02-10 7:44 ` Jean-Philippe Menil @ 2012-02-10 7:54 ` Eric Dumazet 2012-02-10 7:58 ` Jean-Philippe Menil 0 siblings, 1 reply; 8+ messages in thread From: Eric Dumazet @ 2012-02-10 7:54 UTC (permalink / raw) To: jean-philippe.menil; +Cc: Pablo Neira Ayuso, netfilter-devel Le vendredi 10 février 2012 à 08:44 +0100, Jean-Philippe Menil a écrit : > No, the NetlinkEventsReliable is commented in the configuration file. > > However, on the same hosts, i see strange things: > ths host boot with the following parameter: > net.netfilter.nf_conntrack_max=262144 > net.netfilter.nf_conntrack_tcp_timeout_established=10800 > > nf_conntrack is loaded with the following parameter: > options nf_conntrack hashsize=262144 > > But it seems that the nf_conntrack_max reset to his default value > (65536) periodically. > Three days ago, i manually increase the nf_conntrack_max to 262144, > yesterday i see plenty of "nf_conntrack: table full, dropping packet". > checking the value, is fall down to 65536. > > It's maybe not related, but i can't understand how the value can change? > 65536 is the default value when module is loaded. Something unloads it and loads it again, and sysctl is not run after this module load. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: BUG nf_conntrack_ffff880863c50000: Objects remaining on kmem_cache_close() 2012-02-10 7:54 ` Eric Dumazet @ 2012-02-10 7:58 ` Jean-Philippe Menil 2012-02-10 8:13 ` Jean-Philippe Menil 0 siblings, 1 reply; 8+ messages in thread From: Jean-Philippe Menil @ 2012-02-10 7:58 UTC (permalink / raw) To: Eric Dumazet; +Cc: Pablo Neira Ayuso, netfilter-devel Le 10/02/2012 08:54, Eric Dumazet a écrit : > Le vendredi 10 février 2012 à 08:44 +0100, Jean-Philippe Menil a écrit : > >> No, the NetlinkEventsReliable is commented in the configuration file. >> >> However, on the same hosts, i see strange things: >> ths host boot with the following parameter: >> net.netfilter.nf_conntrack_max=262144 >> net.netfilter.nf_conntrack_tcp_timeout_established=10800 >> >> nf_conntrack is loaded with the following parameter: >> options nf_conntrack hashsize=262144 >> >> But it seems that the nf_conntrack_max reset to his default value >> (65536) periodically. >> Three days ago, i manually increase the nf_conntrack_max to 262144, >> yesterday i see plenty of "nf_conntrack: table full, dropping packet". >> checking the value, is fall down to 65536. >> >> It's maybe not related, but i can't understand how the value can change? >> > 65536 is the default value when module is loaded. > > Something unloads it and loads it again, and sysctl is not run after > this module load. > > > > Yes, that's what i'm thinking. And i found the culprit: my lxc guest start with the default value (65536), and it seems to reset the value on the hosts ... -- Jean-Philippe Menil - Pôle réseau Service IRTS DSI Université de Nantes jean-philippe.menil@univ-nantes.fr Tel : 02.53.48.49.27 - Fax : 02.53.48.49.09 -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: BUG nf_conntrack_ffff880863c50000: Objects remaining on kmem_cache_close() 2012-02-10 7:58 ` Jean-Philippe Menil @ 2012-02-10 8:13 ` Jean-Philippe Menil 0 siblings, 0 replies; 8+ messages in thread From: Jean-Philippe Menil @ 2012-02-10 8:13 UTC (permalink / raw) To: Eric Dumazet; +Cc: Pablo Neira Ayuso, netfilter-devel Le 10/02/2012 08:58, Jean-Philippe Menil a écrit : > Le 10/02/2012 08:54, Eric Dumazet a écrit : >> Le vendredi 10 février 2012 à 08:44 +0100, Jean-Philippe Menil a écrit : >> >>> No, the NetlinkEventsReliable is commented in the configuration file. >>> >>> However, on the same hosts, i see strange things: >>> ths host boot with the following parameter: >>> net.netfilter.nf_conntrack_max=262144 >>> net.netfilter.nf_conntrack_tcp_timeout_established=10800 >>> >>> nf_conntrack is loaded with the following parameter: >>> options nf_conntrack hashsize=262144 >>> >>> But it seems that the nf_conntrack_max reset to his default value >>> (65536) periodically. >>> Three days ago, i manually increase the nf_conntrack_max to 262144, >>> yesterday i see plenty of "nf_conntrack: table full, dropping packet". >>> checking the value, is fall down to 65536. >>> >>> It's maybe not related, but i can't understand how the value can >>> change? >>> >> 65536 is the default value when module is loaded. >> >> Something unloads it and loads it again, and sysctl is not run after >> this module load. >> >> >> >> > Yes, that's what i'm thinking. > And i found the culprit: > my lxc guest start with the default value (65536), and it seems to > reset the value on the hosts ... > Dropt the capabilites in the container isn't sufficiant. I need to mount the /proc as read-only ... -- Jean-Philippe Menil - Pôle réseau Service IRTS DSI Université de Nantes jean-philippe.menil@univ-nantes.fr Tel : 02.53.48.49.27 - Fax : 02.53.48.49.09 -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2012-02-10 8:13 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-02-08 14:45 BUG nf_conntrack_ffff880863c50000: Objects remaining on kmem_cache_close() Jean-Philippe Menil 2012-02-09 15:57 ` Pablo Neira Ayuso 2012-02-09 16:11 ` Jean-Philippe Menil 2012-02-09 19:39 ` Pablo Neira Ayuso 2012-02-10 7:44 ` Jean-Philippe Menil 2012-02-10 7:54 ` Eric Dumazet 2012-02-10 7:58 ` Jean-Philippe Menil 2012-02-10 8:13 ` Jean-Philippe Menil
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).