* 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).