* net-next: NULL pointer dereference on adding a net namespace and a system freeze
@ 2014-03-10 0:44 Jakub Kicinski
2014-03-10 4:02 ` Eric Dumazet
0 siblings, 1 reply; 21+ messages in thread
From: Jakub Kicinski @ 2014-03-10 0:44 UTC (permalink / raw)
To: netdev
Hi!
Running Fedora 20 with net-next I get the following warning when
libvirt or rtkit comes up:
[ 272.143488] kmem_cache_sanity_check (flow_cache): Cache name already exists.
[ 272.143586] CPU: 0 PID: 975 Comm: libvirtd Not tainted 3.14.0-rc5+ #1
[ 272.143589] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 272.143591] 0000000000000000 ffff88003ceadba0 ffffffff8167baf0 ffff88003db3d300
[ 272.143595] ffff88003ceadc18 ffffffff8117795b ffff88003ceadbc8 ffff88003b235158
[ 272.143599] 0000000000000000 0000000000040000 0000000000000068 0000000000000000
[ 272.143602] Call Trace:
[ 272.143610] [<ffffffff8167baf0>] dump_stack+0x4d/0x66
[ 272.143615] [<ffffffff8117795b>] kmem_cache_create_memcg+0x12b/0x420
[ 272.143618] [<ffffffff81177c7b>] kmem_cache_create+0x2b/0x30
[ 272.143622] [<ffffffff815c4a0e>] flow_cache_init+0x2e/0x2b0
[ 272.143626] [<ffffffff8164b017>] xfrm_net_init+0x227/0x360
[ 272.143629] [<ffffffff8164af41>] ? xfrm_net_init+0x151/0x360
[ 272.143632] [<ffffffff815a5921>] ops_init+0x41/0x150
[ 272.143635] [<ffffffff815a5aa3>] setup_net+0x73/0x110
[ 272.143638] [<ffffffff815a5fe2>] copy_net_ns+0x72/0x100
[ 272.143642] [<ffffffff810943f9>] create_new_namespaces+0xf9/0x190
[ 272.143645] [<ffffffff81094560>] copy_namespaces+0xd0/0xf0
[ 272.143648] [<ffffffff81094495>] ? copy_namespaces+0x5/0xf0
[ 272.143651] [<ffffffff81069be0>] copy_process.part.31+0x950/0x1b30
[ 272.143655] [<ffffffff8106af95>] do_fork+0xd5/0x370
[ 272.143658] [<ffffffff811c1b2d>] ? __fput+0x17d/0x240
[ 272.143662] [<ffffffff8110440c>] ? __audit_syscall_entry+0x9c/0xf0
[ 272.143665] [<ffffffff8106b2b6>] SyS_clone+0x16/0x20
[ 272.143669] [<ffffffff8168cf19>] stub_clone+0x69/0x90
[ 272.143673] [<ffffffff8168cb69>] ? system_call_fastpath+0x16/0x1b
When I try to add a netns with
# ip netns add abcd
I it dies with:
[ 887.482891] kmem_cache_sanity_check (flow_cache): Cache name already exists.
[ 887.483001] CPU: 0 PID: 1135 Comm: ip Not tainted 3.14.0-rc5+ #1
[ 887.483003] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 887.483036] 0000000000000000 ffff88003bc71d20 ffffffff8167baf0 ffff88003db3d300
[ 887.483041] ffff88003bc71d98 ffffffff8117795b ffff88003bc71d48 ffff88003d88e218
[ 887.483044] 0000000000000000 0000000000040000 0000000000000068 0000000000000000
[ 887.483048] Call Trace:
[ 887.483056] [<ffffffff8167baf0>] dump_stack+0x4d/0x66
[ 887.483060] [<ffffffff8117795b>] kmem_cache_create_memcg+0x12b/0x420
[ 887.483063] [<ffffffff81177c7b>] kmem_cache_create+0x2b/0x30
[ 887.483068] [<ffffffff815c4a0e>] flow_cache_init+0x2e/0x2b0
[ 887.483072] [<ffffffff8164b017>] xfrm_net_init+0x227/0x360
[ 887.483075] [<ffffffff8164af41>] ? xfrm_net_init+0x151/0x360
[ 887.483078] [<ffffffff815a5921>] ops_init+0x41/0x150
[ 887.483081] [<ffffffff815a5aa3>] setup_net+0x73/0x110
[ 887.483084] [<ffffffff815a5fe2>] copy_net_ns+0x72/0x100
[ 887.483088] [<ffffffff810943f9>] create_new_namespaces+0xf9/0x190
[ 887.483092] [<ffffffff81094671>] unshare_nsproxy_namespaces+0x61/0xa0
[ 887.483095] [<ffffffff8106b419>] SyS_unshare+0x159/0x270
[ 887.483099] [<ffffffff8168cb69>] system_call_fastpath+0x16/0x1b
[ 887.484459] BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
[ 887.484546] IP: [<ffffffff81094840>] raw_notifier_chain_register+0x20/0x40
[ 887.484627] PGD 3c183067 PUD 3b1ec067 PMD 0
[ 887.484703] Oops: 0000 [#1] SMP
[ 887.484775] Modules linked in: cfg80211 rfkill xt_conntrack iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw ppdev serio_raw virtio_console virtio_balloon i2c_piix4 floppy parport_pc parport nfsd auth_rpcgss nfs_acl lockd sunrpc virtio_blk virtio_net qxl drm_kms_helper ttm virtio_pci virtio_ring virtio
[ 887.485019] CPU: 0 PID: 1135 Comm: ip Not tainted 3.14.0-rc5+ #1
[ 887.485019] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 887.485019] task: ffff88003b234300 ti: ffff88003bc70000 task.ti: ffff88003bc70000
[ 887.485019] RIP: 0010:[<ffffffff81094840>] [<ffffffff81094840>] raw_notifier_chain_register+0x20/0x40
[ 887.485019] RSP: 0018:ffff88003bc71d98 EFLAGS: 00010202
[ 887.485019] RAX: 0000000000000008 RBX: ffff88003d88e248 RCX: 0000000000000004
[ 887.485019] RDX: 0000000000000000 RSI: ffff88003d88e248 RDI: ffff88003b235190
[ 887.485019] RBP: ffff88003bc71d98 R08: 0000000000000000 R09: 0000000000000000
[ 887.485019] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88003d88e268
[ 887.485019] R13: ffff88003d88e238 R14: ffff88003d88d550 R15: 0000000000000005
[ 887.485019] FS: 00007f7de7389740(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000
[ 887.485019] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 887.485019] CR2: 0000000000000018 CR3: 000000003d1de000 CR4: 00000000000006f0
[ 887.485019] Stack:
[ 887.485019] ffff88003bc71db0 ffffffff81673f4a ffff88003d88d3c0 ffff88003bc71de0
[ 887.485019] ffffffff815c4bbe ffff88003d88d3c0 0000000000000000 ffff88003d88d420
[ 887.485019] ffff88003d88d550 ffff88003bc71e28 ffffffff8164b017 ffffffff8164af41
[ 887.485019] Call Trace:
[ 887.485019] [<ffffffff81673f4a>] register_cpu_notifier+0x2a/0x40
[ 887.485019] [<ffffffff815c4bbe>] flow_cache_init+0x1de/0x2b0
[ 887.485019] [<ffffffff8164b017>] xfrm_net_init+0x227/0x360
[ 887.485019] [<ffffffff8164af41>] ? xfrm_net_init+0x151/0x360
[ 887.485019] [<ffffffff815a5921>] ops_init+0x41/0x150
[ 887.485019] [<ffffffff815a5aa3>] setup_net+0x73/0x110
[ 887.485019] [<ffffffff815a5fe2>] copy_net_ns+0x72/0x100
[ 887.485019] [<ffffffff810943f9>] create_new_namespaces+0xf9/0x190
[ 887.485019] [<ffffffff81094671>] unshare_nsproxy_namespaces+0x61/0xa0
[ 887.485019] [<ffffffff8106b419>] SyS_unshare+0x159/0x270
[ 887.485019] [<ffffffff8168cb69>] system_call_fastpath+0x16/0x1b
[ 887.485019] Code: 4c 63 f8 e9 7b ff ff ff 0f 1f 00 66 66 66 66 90 55 48 8b 07 48 89 e5 48 85 c0 74 21 8b 56 10 3b 50 10 7e 0c eb 17 0f 1f 44 00 00 <39> 50 10 7c 0d 48 8d 78 08 48 8b 40 08 48 85 c0 75 ee 48 89 46
[ 887.485019] RIP [<ffffffff81094840>] raw_notifier_chain_register+0x20/0x40
[ 887.485019] RSP <ffff88003bc71d98>
[ 887.485019] CR2: 0000000000000018
If I let the machine run for a few minutes (without adding netns, just
with libvirtd running), I get the following:
[ 1173.850646] WARNING: CPU: 1 PID: 0 at /home/kuba/Development/Linux/net-next/lib/list_debug.c:33 __list_add+0xac/0xc0()
[ 1173.850892] list_add corruption. prev->next should be next (ffffffff81e8e648), but was 0000000000010000. (prev=ffff88003b2351a8).
[ 1173.851333] Modules linked in: cfg80211 rfkill xt_conntrack iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw ppdev serio_raw virtio_console virtio_balloon i2c_piix4 floppy parport_pc parport nfsd auth_rpcgss nfs_acl lockd sunrpc virtio_blk virtio_net qxl drm_kms_helper ttm virtio_pci virtio_ring virtio
[ 1173.851576] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G D 3.14.0-rc5+ #1
[ 1173.851576] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 1173.851576] 0000000000000009 ffff88003fd03928 ffffffff8167baf0 ffff88003fd03970
[ 1173.851576] ffff88003fd03960 ffffffff8106bd5d ffff88003bee03e0 ffffffff81e8e648
[ 1173.851576] ffff88003b2351a8 ffffffff81e8d180 000000010011e95a ffff88003fd039c0
[ 1173.851576] Call Trace:
[ 1173.851576] <IRQ> [<ffffffff8167baf0>] dump_stack+0x4d/0x66
[ 1173.851576] [<ffffffff8106bd5d>] warn_slowpath_common+0x7d/0xa0
[ 1173.851576] [<ffffffff8106bdcc>] warn_slowpath_fmt+0x4c/0x50
[ 1173.851576] [<ffffffff813217ac>] __list_add+0xac/0xc0
[ 1173.851576] [<ffffffff810778b3>] __internal_add_timer+0x113/0x130
[ 1173.851576] [<ffffffff81077ac7>] internal_add_timer+0x17/0x40
[ 1173.851576] [<ffffffff8107a1fd>] mod_timer_pending+0xfd/0x190
[ 1173.851576] [<ffffffffa0171748>] __nf_ct_refresh_acct+0xb8/0xd0 [nf_conntrack]
[ 1173.851576] [<ffffffffa01793a0>] tcp_packet+0x6c0/0x14c0 [nf_conntrack]
[ 1173.851576] [<ffffffffa01729bd>] ? __nf_conntrack_find_get+0x2fd/0x350 [nf_conntrack]
[ 1173.851576] [<ffffffffa01726c5>] ? __nf_conntrack_find_get+0x5/0x350 [nf_conntrack]
[ 1173.851576] [<ffffffffa017393c>] nf_conntrack_in+0x34c/0xa00 [nf_conntrack]
[ 1173.851576] [<ffffffff815ea050>] ? ip_local_deliver_finish+0x330/0x330
[ 1173.851576] [<ffffffffa019e2d2>] ipv4_conntrack_in+0x22/0x30 [nf_conntrack_ipv4]
[ 1173.851576] [<ffffffff815e085a>] nf_iterate+0x9a/0xb0
[ 1173.851576] [<ffffffff815ea050>] ? ip_local_deliver_finish+0x330/0x330
[ 1173.851576] [<ffffffff815e0914>] nf_hook_slow+0xa4/0x170
[ 1173.851576] [<ffffffff815ea050>] ? ip_local_deliver_finish+0x330/0x330
[ 1173.851576] [<ffffffff815eab48>] ip_rcv+0x2f8/0x3d0
[ 1173.851576] [<ffffffff815ade16>] __netif_receive_skb_core+0x6c6/0x8b0
[ 1173.851576] [<ffffffff815ad852>] ? __netif_receive_skb_core+0x102/0x8b0
[ 1173.851576] [<ffffffff815ae018>] __netif_receive_skb+0x18/0x60
[ 1173.851576] [<ffffffff815ae093>] netif_receive_skb_internal+0x33/0x120
[ 1173.851576] [<ffffffff815ae19c>] netif_receive_skb+0x1c/0x70
[ 1173.851576] [<ffffffffa00166ea>] virtnet_poll+0x4ea/0x840 [virtio_net]
[ 1173.851576] [<ffffffff815ae56a>] net_rx_action+0x15a/0x270
[ 1173.851576] [<ffffffff81071345>] __do_softirq+0xf5/0x2b0
[ 1173.851576] [<ffffffff8107177d>] irq_exit+0xbd/0xd0
[ 1173.851576] [<ffffffff8168ea48>] do_IRQ+0x58/0xf0
[ 1173.851576] [<ffffffff81683fed>] common_interrupt+0x6d/0x6d
[ 1173.851576] <EOI> [<ffffffff81687dd5>] ? __atomic_notifier_call_chain+0x5/0xa0
[ 1173.851576] [<ffffffff8103b3f6>] ? native_safe_halt+0x6/0x10
[ 1173.851576] [<ffffffff8100b8cf>] default_idle+0x1f/0xe0
[ 1173.851576] [<ffffffff8100c206>] arch_cpu_idle+0x26/0x30
[ 1173.851576] [<ffffffff810c8d5e>] cpu_startup_entry+0x9e/0x260
[ 1173.851576] [<ffffffff8102ec04>] start_secondary+0x1d4/0x280
Or a similar warning related to adding a timer to the list (not
necessarily network related timer). After a few seconds/minutes the
machine freezes (I guess it happens when the broken timer fires).
It didn't happen on wireless-testing from a week ago, but I didn't have
time today to bisect :/
-- kuba
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: net-next: NULL pointer dereference on adding a net namespace and a system freeze
2014-03-10 0:44 net-next: NULL pointer dereference on adding a net namespace and a system freeze Jakub Kicinski
@ 2014-03-10 4:02 ` Eric Dumazet
2014-03-10 4:09 ` Eric Dumazet
0 siblings, 1 reply; 21+ messages in thread
From: Eric Dumazet @ 2014-03-10 4:02 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: netdev, Fan Du, Steffen Klassert
On Mon, 2014-03-10 at 01:44 +0100, Jakub Kicinski wrote:
> Hi!
>
> Running Fedora 20 with net-next I get the following warning when
> libvirt or rtkit comes up:
>
> [ 272.143488] kmem_cache_sanity_check (flow_cache): Cache name already exists.
> [ 272.143586] CPU: 0 PID: 975 Comm: libvirtd Not tainted 3.14.0-rc5+ #1
> [ 272.143589] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> [ 272.143591] 0000000000000000 ffff88003ceadba0 ffffffff8167baf0 ffff88003db3d300
> [ 272.143595] ffff88003ceadc18 ffffffff8117795b ffff88003ceadbc8 ffff88003b235158
> [ 272.143599] 0000000000000000 0000000000040000 0000000000000068 0000000000000000
> [ 272.143602] Call Trace:
> [ 272.143610] [<ffffffff8167baf0>] dump_stack+0x4d/0x66
> [ 272.143615] [<ffffffff8117795b>] kmem_cache_create_memcg+0x12b/0x420
> [ 272.143618] [<ffffffff81177c7b>] kmem_cache_create+0x2b/0x30
> [ 272.143622] [<ffffffff815c4a0e>] flow_cache_init+0x2e/0x2b0
> [ 272.143626] [<ffffffff8164b017>] xfrm_net_init+0x227/0x360
> [ 272.143629] [<ffffffff8164af41>] ? xfrm_net_init+0x151/0x360
> [ 272.143632] [<ffffffff815a5921>] ops_init+0x41/0x150
> [ 272.143635] [<ffffffff815a5aa3>] setup_net+0x73/0x110
> [ 272.143638] [<ffffffff815a5fe2>] copy_net_ns+0x72/0x100
> [ 272.143642] [<ffffffff810943f9>] create_new_namespaces+0xf9/0x190
> [ 272.143645] [<ffffffff81094560>] copy_namespaces+0xd0/0xf0
> [ 272.143648] [<ffffffff81094495>] ? copy_namespaces+0x5/0xf0
> [ 272.143651] [<ffffffff81069be0>] copy_process.part.31+0x950/0x1b30
> [ 272.143655] [<ffffffff8106af95>] do_fork+0xd5/0x370
> [ 272.143658] [<ffffffff811c1b2d>] ? __fput+0x17d/0x240
> [ 272.143662] [<ffffffff8110440c>] ? __audit_syscall_entry+0x9c/0xf0
> [ 272.143665] [<ffffffff8106b2b6>] SyS_clone+0x16/0x20
> [ 272.143669] [<ffffffff8168cf19>] stub_clone+0x69/0x90
> [ 272.143673] [<ffffffff8168cb69>] ? system_call_fastpath+0x16/0x1b
>
>
> When I try to add a netns with
> # ip netns add abcd
> I it dies with:
Yep, commit ca925cf1534ebcec332c08719a7dee6ee1782ce4 is buggy.
flowcache: Make flow cache name space aware
Inserting a entry into flowcache, or flushing flowcache should be based
on per net scope. The reason to do so is flushing operation from fat
netns crammed with flow entries will also making the slim netns with only
a few flow cache entries go away in original implementation.
Since flowcache is tightly coupled with IPsec, so it would be easier to
put flow cache global parameters into xfrm namespace part. And one last
thing needs to do is bumping flow cache genid, and flush flow cache should
also be made in per net style.
Signed-off-by: Fan Du <fan.du@windriver.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
I fail to understand why the kmem_cache must be private to a netns.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: net-next: NULL pointer dereference on adding a net namespace and a system freeze
2014-03-10 4:02 ` Eric Dumazet
@ 2014-03-10 4:09 ` Eric Dumazet
2014-03-10 6:51 ` Fan Du
2014-03-10 12:19 ` net-next: NULL pointer dereference on adding a net namespace and a system freeze Jakub Kiciński
0 siblings, 2 replies; 21+ messages in thread
From: Eric Dumazet @ 2014-03-10 4:09 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: netdev, Fan Du, Steffen Klassert
On Sun, 2014-03-09 at 21:02 -0700, Eric Dumazet wrote:
> On Mon, 2014-03-10 at 01:44 +0100, Jakub Kicinski wrote:
> > Hi!
> >
> > Running Fedora 20 with net-next I get the following warning when
> > libvirt or rtkit comes up:
> >
> > [ 272.143488] kmem_cache_sanity_check (flow_cache): Cache name already exists.
> > [ 272.143586] CPU: 0 PID: 975 Comm: libvirtd Not tainted 3.14.0-rc5+ #1
> > [ 272.143589] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> > [ 272.143591] 0000000000000000 ffff88003ceadba0 ffffffff8167baf0 ffff88003db3d300
> > [ 272.143595] ffff88003ceadc18 ffffffff8117795b ffff88003ceadbc8 ffff88003b235158
> > [ 272.143599] 0000000000000000 0000000000040000 0000000000000068 0000000000000000
> > [ 272.143602] Call Trace:
> > [ 272.143610] [<ffffffff8167baf0>] dump_stack+0x4d/0x66
> > [ 272.143615] [<ffffffff8117795b>] kmem_cache_create_memcg+0x12b/0x420
> > [ 272.143618] [<ffffffff81177c7b>] kmem_cache_create+0x2b/0x30
> > [ 272.143622] [<ffffffff815c4a0e>] flow_cache_init+0x2e/0x2b0
> > [ 272.143626] [<ffffffff8164b017>] xfrm_net_init+0x227/0x360
> > [ 272.143629] [<ffffffff8164af41>] ? xfrm_net_init+0x151/0x360
> > [ 272.143632] [<ffffffff815a5921>] ops_init+0x41/0x150
> > [ 272.143635] [<ffffffff815a5aa3>] setup_net+0x73/0x110
> > [ 272.143638] [<ffffffff815a5fe2>] copy_net_ns+0x72/0x100
> > [ 272.143642] [<ffffffff810943f9>] create_new_namespaces+0xf9/0x190
> > [ 272.143645] [<ffffffff81094560>] copy_namespaces+0xd0/0xf0
> > [ 272.143648] [<ffffffff81094495>] ? copy_namespaces+0x5/0xf0
> > [ 272.143651] [<ffffffff81069be0>] copy_process.part.31+0x950/0x1b30
> > [ 272.143655] [<ffffffff8106af95>] do_fork+0xd5/0x370
> > [ 272.143658] [<ffffffff811c1b2d>] ? __fput+0x17d/0x240
> > [ 272.143662] [<ffffffff8110440c>] ? __audit_syscall_entry+0x9c/0xf0
> > [ 272.143665] [<ffffffff8106b2b6>] SyS_clone+0x16/0x20
> > [ 272.143669] [<ffffffff8168cf19>] stub_clone+0x69/0x90
> > [ 272.143673] [<ffffffff8168cb69>] ? system_call_fastpath+0x16/0x1b
> >
> >
> > When I try to add a netns with
> > # ip netns add abcd
> > I it dies with:
>
>
> Yep, commit ca925cf1534ebcec332c08719a7dee6ee1782ce4 is buggy.
>
> flowcache: Make flow cache name space aware
>
> Inserting a entry into flowcache, or flushing flowcache should be based
> on per net scope. The reason to do so is flushing operation from fat
> netns crammed with flow entries will also making the slim netns with only
> a few flow cache entries go away in original implementation.
>
> Since flowcache is tightly coupled with IPsec, so it would be easier to
> put flow cache global parameters into xfrm namespace part. And one last
> thing needs to do is bumping flow cache genid, and flush flow cache should
> also be made in per net style.
>
> Signed-off-by: Fan Du <fan.du@windriver.com>
> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
>
> I fail to understand why the kmem_cache must be private to a netns.
Could you please try the following patch ?
diff --git a/include/net/netns/xfrm.h b/include/net/netns/xfrm.h
index 51f0dce7b643..3492434baf88 100644
--- a/include/net/netns/xfrm.h
+++ b/include/net/netns/xfrm.h
@@ -64,7 +64,6 @@ struct netns_xfrm {
/* flow cache part */
struct flow_cache flow_cache_global;
- struct kmem_cache *flow_cachep;
atomic_t flow_cache_genid;
struct list_head flow_cache_gc_list;
spinlock_t flow_cache_gc_lock;
diff --git a/net/core/flow.c b/net/core/flow.c
index 344a184011fd..102f8ea2eb6e 100644
--- a/net/core/flow.c
+++ b/net/core/flow.c
@@ -45,6 +45,8 @@ struct flow_flush_info {
struct completion completion;
};
+static struct kmem_cache *flow_cachep __read_mostly;
+
#define flow_cache_hash_size(cache) (1 << (cache)->hash_shift)
#define FLOW_HASH_RND_PERIOD (10 * 60 * HZ)
@@ -75,7 +77,7 @@ static void flow_entry_kill(struct flow_cache_entry *fle,
{
if (fle->object)
fle->object->ops->delete(fle->object);
- kmem_cache_free(xfrm->flow_cachep, fle);
+ kmem_cache_free(flow_cachep, fle);
}
static void flow_cache_gc_task(struct work_struct *work)
@@ -230,7 +232,7 @@ flow_cache_lookup(struct net *net, const struct flowi *key, u16 family, u8 dir,
if (fcp->hash_count > fc->high_watermark)
flow_cache_shrink(fc, fcp);
- fle = kmem_cache_alloc(net->xfrm.flow_cachep, GFP_ATOMIC);
+ fle = kmem_cache_alloc(flow_cachep, GFP_ATOMIC);
if (fle) {
fle->net = net;
fle->family = family;
@@ -435,10 +437,10 @@ int flow_cache_init(struct net *net)
int i;
struct flow_cache *fc = &net->xfrm.flow_cache_global;
- /* Initialize per-net flow cache global variables here */
- net->xfrm.flow_cachep = kmem_cache_create("flow_cache",
- sizeof(struct flow_cache_entry),
- 0, SLAB_PANIC, NULL);
+ if (!flow_cachep)
+ flow_cachep = kmem_cache_create("flow_cache",
+ sizeof(struct flow_cache_entry),
+ 0, SLAB_PANIC, NULL);
spin_lock_init(&net->xfrm.flow_cache_gc_lock);
INIT_LIST_HEAD(&net->xfrm.flow_cache_gc_list);
INIT_WORK(&net->xfrm.flow_cache_gc_work, flow_cache_gc_task);
^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: net-next: NULL pointer dereference on adding a net namespace and a system freeze
2014-03-10 4:09 ` Eric Dumazet
@ 2014-03-10 6:51 ` Fan Du
2014-03-10 13:44 ` Eric Dumazet
2014-03-10 12:19 ` net-next: NULL pointer dereference on adding a net namespace and a system freeze Jakub Kiciński
1 sibling, 1 reply; 21+ messages in thread
From: Fan Du @ 2014-03-10 6:51 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Jakub Kicinski, netdev, Steffen Klassert
On 2014年03月10日 12:09, Eric Dumazet wrote:
> On Sun, 2014-03-09 at 21:02 -0700, Eric Dumazet wrote:
>> On Mon, 2014-03-10 at 01:44 +0100, Jakub Kicinski wrote:
>>> Hi!
>>>
>>> Running Fedora 20 with net-next I get the following warning when
>>> libvirt or rtkit comes up:
>>>
>>> [ 272.143488] kmem_cache_sanity_check (flow_cache): Cache name already exists.
>>> [ 272.143586] CPU: 0 PID: 975 Comm: libvirtd Not tainted 3.14.0-rc5+ #1
>>> [ 272.143589] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
>>> [ 272.143591] 0000000000000000 ffff88003ceadba0 ffffffff8167baf0 ffff88003db3d300
>>> [ 272.143595] ffff88003ceadc18 ffffffff8117795b ffff88003ceadbc8 ffff88003b235158
>>> [ 272.143599] 0000000000000000 0000000000040000 0000000000000068 0000000000000000
>>> [ 272.143602] Call Trace:
>>> [ 272.143610] [<ffffffff8167baf0>] dump_stack+0x4d/0x66
>>> [ 272.143615] [<ffffffff8117795b>] kmem_cache_create_memcg+0x12b/0x420
>>> [ 272.143618] [<ffffffff81177c7b>] kmem_cache_create+0x2b/0x30
>>> [ 272.143622] [<ffffffff815c4a0e>] flow_cache_init+0x2e/0x2b0
>>> [ 272.143626] [<ffffffff8164b017>] xfrm_net_init+0x227/0x360
>>> [ 272.143629] [<ffffffff8164af41>] ? xfrm_net_init+0x151/0x360
>>> [ 272.143632] [<ffffffff815a5921>] ops_init+0x41/0x150
>>> [ 272.143635] [<ffffffff815a5aa3>] setup_net+0x73/0x110
>>> [ 272.143638] [<ffffffff815a5fe2>] copy_net_ns+0x72/0x100
>>> [ 272.143642] [<ffffffff810943f9>] create_new_namespaces+0xf9/0x190
>>> [ 272.143645] [<ffffffff81094560>] copy_namespaces+0xd0/0xf0
>>> [ 272.143648] [<ffffffff81094495>] ? copy_namespaces+0x5/0xf0
>>> [ 272.143651] [<ffffffff81069be0>] copy_process.part.31+0x950/0x1b30
>>> [ 272.143655] [<ffffffff8106af95>] do_fork+0xd5/0x370
>>> [ 272.143658] [<ffffffff811c1b2d>] ? __fput+0x17d/0x240
>>> [ 272.143662] [<ffffffff8110440c>] ? __audit_syscall_entry+0x9c/0xf0
>>> [ 272.143665] [<ffffffff8106b2b6>] SyS_clone+0x16/0x20
>>> [ 272.143669] [<ffffffff8168cf19>] stub_clone+0x69/0x90
>>> [ 272.143673] [<ffffffff8168cb69>] ? system_call_fastpath+0x16/0x1b
>>>
>>>
>>> When I try to add a netns with
>>> # ip netns add abcd
>>> I it dies with:
>>
>>
>> Yep, commit ca925cf1534ebcec332c08719a7dee6ee1782ce4 is buggy.
>>
>> flowcache: Make flow cache name space aware
>>
>> Inserting a entry into flowcache, or flushing flowcache should be based
>> on per net scope. The reason to do so is flushing operation from fat
>> netns crammed with flow entries will also making the slim netns with only
>> a few flow cache entries go away in original implementation.
>>
>> Since flowcache is tightly coupled with IPsec, so it would be easier to
>> put flow cache global parameters into xfrm namespace part. And one last
>> thing needs to do is bumping flow cache genid, and flush flow cache should
>> also be made in per net style.
>>
>> Signed-off-by: Fan Du<fan.du@windriver.com>
>> Signed-off-by: Steffen Klassert<steffen.klassert@secunet.com>
>>
>> I fail to understand why the kmem_cache must be private to a netns.
Sorry, I didn't turn on CONFIG_DEBUG_VM before...
Sometimes network activity only on netns could trigger bugs like memory leakage,
using per-netns kmem_cache could help to identify which netns to be blamed.
Anyway if this is inappropriate, let's make it global as you did below.
> Could you please try the following patch ?
>
Tested-by: Fan Du <fan.du@windriver.com>
> diff --git a/include/net/netns/xfrm.h b/include/net/netns/xfrm.h
> index 51f0dce7b643..3492434baf88 100644
> --- a/include/net/netns/xfrm.h
> +++ b/include/net/netns/xfrm.h
> @@ -64,7 +64,6 @@ struct netns_xfrm {
>
> /* flow cache part */
> struct flow_cache flow_cache_global;
> - struct kmem_cache *flow_cachep;
> atomic_t flow_cache_genid;
> struct list_head flow_cache_gc_list;
> spinlock_t flow_cache_gc_lock;
> diff --git a/net/core/flow.c b/net/core/flow.c
> index 344a184011fd..102f8ea2eb6e 100644
> --- a/net/core/flow.c
> +++ b/net/core/flow.c
> @@ -45,6 +45,8 @@ struct flow_flush_info {
> struct completion completion;
> };
>
> +static struct kmem_cache *flow_cachep __read_mostly;
> +
> #define flow_cache_hash_size(cache) (1<< (cache)->hash_shift)
> #define FLOW_HASH_RND_PERIOD (10 * 60 * HZ)
>
> @@ -75,7 +77,7 @@ static void flow_entry_kill(struct flow_cache_entry *fle,
> {
> if (fle->object)
> fle->object->ops->delete(fle->object);
> - kmem_cache_free(xfrm->flow_cachep, fle);
> + kmem_cache_free(flow_cachep, fle);
> }
>
> static void flow_cache_gc_task(struct work_struct *work)
> @@ -230,7 +232,7 @@ flow_cache_lookup(struct net *net, const struct flowi *key, u16 family, u8 dir,
> if (fcp->hash_count> fc->high_watermark)
> flow_cache_shrink(fc, fcp);
>
> - fle = kmem_cache_alloc(net->xfrm.flow_cachep, GFP_ATOMIC);
> + fle = kmem_cache_alloc(flow_cachep, GFP_ATOMIC);
> if (fle) {
> fle->net = net;
> fle->family = family;
> @@ -435,10 +437,10 @@ int flow_cache_init(struct net *net)
> int i;
> struct flow_cache *fc =&net->xfrm.flow_cache_global;
>
> - /* Initialize per-net flow cache global variables here */
> - net->xfrm.flow_cachep = kmem_cache_create("flow_cache",
> - sizeof(struct flow_cache_entry),
> - 0, SLAB_PANIC, NULL);
> + if (!flow_cachep)
> + flow_cachep = kmem_cache_create("flow_cache",
> + sizeof(struct flow_cache_entry),
> + 0, SLAB_PANIC, NULL);
> spin_lock_init(&net->xfrm.flow_cache_gc_lock);
> INIT_LIST_HEAD(&net->xfrm.flow_cache_gc_list);
> INIT_WORK(&net->xfrm.flow_cache_gc_work, flow_cache_gc_task);
>
>
>
--
浮沉随浪只记今朝笑
--fan
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: net-next: NULL pointer dereference on adding a net namespace and a system freeze
2014-03-10 4:09 ` Eric Dumazet
2014-03-10 6:51 ` Fan Du
@ 2014-03-10 12:19 ` Jakub Kiciński
2014-03-10 14:04 ` Eric Dumazet
1 sibling, 1 reply; 21+ messages in thread
From: Jakub Kiciński @ 2014-03-10 12:19 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Fan Du, Steffen Klassert
On Sun, 09 Mar 2014 21:09:17 -0700, Eric Dumazet wrote:
> On Sun, 2014-03-09 at 21:02 -0700, Eric Dumazet wrote:
> > On Mon, 2014-03-10 at 01:44 +0100, Jakub Kicinski wrote:
> > > Hi!
> > >
> > > Running Fedora 20 with net-next I get the following warning when
> > > libvirt or rtkit comes up:
> > >
> > > [ 272.143488] kmem_cache_sanity_check (flow_cache): Cache name already exists.
> > > [ 272.143586] CPU: 0 PID: 975 Comm: libvirtd Not tainted 3.14.0-rc5+ #1
> > > [ 272.143589] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> > > [ 272.143591] 0000000000000000 ffff88003ceadba0 ffffffff8167baf0 ffff88003db3d300
> > > [ 272.143595] ffff88003ceadc18 ffffffff8117795b ffff88003ceadbc8 ffff88003b235158
> > > [ 272.143599] 0000000000000000 0000000000040000 0000000000000068 0000000000000000
> > > [ 272.143602] Call Trace:
> > > [ 272.143610] [<ffffffff8167baf0>] dump_stack+0x4d/0x66
> > > [ 272.143615] [<ffffffff8117795b>] kmem_cache_create_memcg+0x12b/0x420
> > > [ 272.143618] [<ffffffff81177c7b>] kmem_cache_create+0x2b/0x30
> > > [ 272.143622] [<ffffffff815c4a0e>] flow_cache_init+0x2e/0x2b0
> > > [ 272.143626] [<ffffffff8164b017>] xfrm_net_init+0x227/0x360
> > > [ 272.143629] [<ffffffff8164af41>] ? xfrm_net_init+0x151/0x360
> > > [ 272.143632] [<ffffffff815a5921>] ops_init+0x41/0x150
> > > [ 272.143635] [<ffffffff815a5aa3>] setup_net+0x73/0x110
> > > [ 272.143638] [<ffffffff815a5fe2>] copy_net_ns+0x72/0x100
> > > [ 272.143642] [<ffffffff810943f9>] create_new_namespaces+0xf9/0x190
> > > [ 272.143645] [<ffffffff81094560>] copy_namespaces+0xd0/0xf0
> > > [ 272.143648] [<ffffffff81094495>] ? copy_namespaces+0x5/0xf0
> > > [ 272.143651] [<ffffffff81069be0>] copy_process.part.31+0x950/0x1b30
> > > [ 272.143655] [<ffffffff8106af95>] do_fork+0xd5/0x370
> > > [ 272.143658] [<ffffffff811c1b2d>] ? __fput+0x17d/0x240
> > > [ 272.143662] [<ffffffff8110440c>] ? __audit_syscall_entry+0x9c/0xf0
> > > [ 272.143665] [<ffffffff8106b2b6>] SyS_clone+0x16/0x20
> > > [ 272.143669] [<ffffffff8168cf19>] stub_clone+0x69/0x90
> > > [ 272.143673] [<ffffffff8168cb69>] ? system_call_fastpath+0x16/0x1b
> > >
> > >
> > > When I try to add a netns with
> > > # ip netns add abcd
> > > I it dies with:
> >
> >
> > Yep, commit ca925cf1534ebcec332c08719a7dee6ee1782ce4 is buggy.
> >
> > flowcache: Make flow cache name space aware
> >
> > Inserting a entry into flowcache, or flushing flowcache should be based
> > on per net scope. The reason to do so is flushing operation from fat
> > netns crammed with flow entries will also making the slim netns with only
> > a few flow cache entries go away in original implementation.
> >
> > Since flowcache is tightly coupled with IPsec, so it would be easier to
> > put flow cache global parameters into xfrm namespace part. And one last
> > thing needs to do is bumping flow cache genid, and flush flow cache should
> > also be made in per net style.
> >
> > Signed-off-by: Fan Du <fan.du@windriver.com>
> > Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
> >
> > I fail to understand why the kmem_cache must be private to a netns.
>
> Could you please try the following patch ?
It helps with the flow_cache warning and BUG ("ip netns add" works) but
machine still freezes after 5-10 minutes. I will try to revert
ca925cf1534ebcec332c08719a7dee6ee1782ce4 and see if that solves it.
-- kuba
> diff --git a/include/net/netns/xfrm.h b/include/net/netns/xfrm.h
> index 51f0dce7b643..3492434baf88 100644
> --- a/include/net/netns/xfrm.h
> +++ b/include/net/netns/xfrm.h
> @@ -64,7 +64,6 @@ struct netns_xfrm {
>
> /* flow cache part */
> struct flow_cache flow_cache_global;
> - struct kmem_cache *flow_cachep;
> atomic_t flow_cache_genid;
> struct list_head flow_cache_gc_list;
> spinlock_t flow_cache_gc_lock;
> diff --git a/net/core/flow.c b/net/core/flow.c
> index 344a184011fd..102f8ea2eb6e 100644
> --- a/net/core/flow.c
> +++ b/net/core/flow.c
> @@ -45,6 +45,8 @@ struct flow_flush_info {
> struct completion completion;
> };
>
> +static struct kmem_cache *flow_cachep __read_mostly;
> +
> #define flow_cache_hash_size(cache) (1 << (cache)->hash_shift)
> #define FLOW_HASH_RND_PERIOD (10 * 60 * HZ)
>
> @@ -75,7 +77,7 @@ static void flow_entry_kill(struct flow_cache_entry *fle,
> {
> if (fle->object)
> fle->object->ops->delete(fle->object);
> - kmem_cache_free(xfrm->flow_cachep, fle);
> + kmem_cache_free(flow_cachep, fle);
> }
>
> static void flow_cache_gc_task(struct work_struct *work)
> @@ -230,7 +232,7 @@ flow_cache_lookup(struct net *net, const struct flowi *key, u16 family, u8 dir,
> if (fcp->hash_count > fc->high_watermark)
> flow_cache_shrink(fc, fcp);
>
> - fle = kmem_cache_alloc(net->xfrm.flow_cachep, GFP_ATOMIC);
> + fle = kmem_cache_alloc(flow_cachep, GFP_ATOMIC);
> if (fle) {
> fle->net = net;
> fle->family = family;
> @@ -435,10 +437,10 @@ int flow_cache_init(struct net *net)
> int i;
> struct flow_cache *fc = &net->xfrm.flow_cache_global;
>
> - /* Initialize per-net flow cache global variables here */
> - net->xfrm.flow_cachep = kmem_cache_create("flow_cache",
> - sizeof(struct flow_cache_entry),
> - 0, SLAB_PANIC, NULL);
> + if (!flow_cachep)
> + flow_cachep = kmem_cache_create("flow_cache",
> + sizeof(struct flow_cache_entry),
> + 0, SLAB_PANIC, NULL);
> spin_lock_init(&net->xfrm.flow_cache_gc_lock);
> INIT_LIST_HEAD(&net->xfrm.flow_cache_gc_list);
> INIT_WORK(&net->xfrm.flow_cache_gc_work, flow_cache_gc_task);
>
>
>
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: net-next: NULL pointer dereference on adding a net namespace and a system freeze
2014-03-10 6:51 ` Fan Du
@ 2014-03-10 13:44 ` Eric Dumazet
2014-03-10 14:09 ` [PATCH net-next] flowcache: restore a single flow_cache kmem_cache Eric Dumazet
0 siblings, 1 reply; 21+ messages in thread
From: Eric Dumazet @ 2014-03-10 13:44 UTC (permalink / raw)
To: Fan Du; +Cc: Jakub Kicinski, netdev, Steffen Klassert
On Mon, 2014-03-10 at 14:51 +0800, Fan Du wrote:
> Sometimes network activity only on netns could trigger bugs like memory leakage,
> using per-netns kmem_cache could help to identify which netns to be blamed.
>
> Anyway if this is inappropriate, let's make it global as you did below.
But you forgot to kmem_cache_destroy() the cache at netns removal, so
this also is a leak ;)
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: net-next: NULL pointer dereference on adding a net namespace and a system freeze
2014-03-10 12:19 ` net-next: NULL pointer dereference on adding a net namespace and a system freeze Jakub Kiciński
@ 2014-03-10 14:04 ` Eric Dumazet
2014-03-11 0:46 ` Jakub Kiciński
0 siblings, 1 reply; 21+ messages in thread
From: Eric Dumazet @ 2014-03-10 14:04 UTC (permalink / raw)
To: Jakub Kiciński; +Cc: netdev, Fan Du, Steffen Klassert
On Mon, 2014-03-10 at 13:19 +0100, Jakub Kiciński wrote:
> It helps with the flow_cache warning and BUG ("ip netns add" works) but
> machine still freezes after 5-10 minutes. I will try to revert
> ca925cf1534ebcec332c08719a7dee6ee1782ce4 and see if that solves it.
I think the other issue is separate. It might be triggered by
conntracking change.
Thanks !
^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH net-next] flowcache: restore a single flow_cache kmem_cache
2014-03-10 13:44 ` Eric Dumazet
@ 2014-03-10 14:09 ` Eric Dumazet
2014-03-11 1:45 ` David Miller
0 siblings, 1 reply; 21+ messages in thread
From: Eric Dumazet @ 2014-03-10 14:09 UTC (permalink / raw)
To: Fan Du; +Cc: Jakub Kicinski, netdev, Steffen Klassert
From: Eric Dumazet <edumazet@google.com>
It is not legal to create multiple kmem_cache having the same name.
flowcache can use a single kmem_cache, no need for a per netns
one.
Fixes: ca925cf1534e ("flowcache: Make flow cache name space aware")
Reported-by: Jakub Kicinski <moorray3@wp.pl>
Tested-by: Jakub Kicinski <moorray3@wp.pl>
Tested-by: Fan Du <fan.du@windriver.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
include/net/netns/xfrm.h | 1 -
net/core/flow.c | 14 ++++++++------
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/include/net/netns/xfrm.h b/include/net/netns/xfrm.h
index 51f0dce7b643..3492434baf88 100644
--- a/include/net/netns/xfrm.h
+++ b/include/net/netns/xfrm.h
@@ -64,7 +64,6 @@ struct netns_xfrm {
/* flow cache part */
struct flow_cache flow_cache_global;
- struct kmem_cache *flow_cachep;
atomic_t flow_cache_genid;
struct list_head flow_cache_gc_list;
spinlock_t flow_cache_gc_lock;
diff --git a/net/core/flow.c b/net/core/flow.c
index 344a184011fd..102f8ea2eb6e 100644
--- a/net/core/flow.c
+++ b/net/core/flow.c
@@ -45,6 +45,8 @@ struct flow_flush_info {
struct completion completion;
};
+static struct kmem_cache *flow_cachep __read_mostly;
+
#define flow_cache_hash_size(cache) (1 << (cache)->hash_shift)
#define FLOW_HASH_RND_PERIOD (10 * 60 * HZ)
@@ -75,7 +77,7 @@ static void flow_entry_kill(struct flow_cache_entry *fle,
{
if (fle->object)
fle->object->ops->delete(fle->object);
- kmem_cache_free(xfrm->flow_cachep, fle);
+ kmem_cache_free(flow_cachep, fle);
}
static void flow_cache_gc_task(struct work_struct *work)
@@ -230,7 +232,7 @@ flow_cache_lookup(struct net *net, const struct flowi *key, u16 family, u8 dir,
if (fcp->hash_count > fc->high_watermark)
flow_cache_shrink(fc, fcp);
- fle = kmem_cache_alloc(net->xfrm.flow_cachep, GFP_ATOMIC);
+ fle = kmem_cache_alloc(flow_cachep, GFP_ATOMIC);
if (fle) {
fle->net = net;
fle->family = family;
@@ -435,10 +437,10 @@ int flow_cache_init(struct net *net)
int i;
struct flow_cache *fc = &net->xfrm.flow_cache_global;
- /* Initialize per-net flow cache global variables here */
- net->xfrm.flow_cachep = kmem_cache_create("flow_cache",
- sizeof(struct flow_cache_entry),
- 0, SLAB_PANIC, NULL);
+ if (!flow_cachep)
+ flow_cachep = kmem_cache_create("flow_cache",
+ sizeof(struct flow_cache_entry),
+ 0, SLAB_PANIC, NULL);
spin_lock_init(&net->xfrm.flow_cache_gc_lock);
INIT_LIST_HEAD(&net->xfrm.flow_cache_gc_list);
INIT_WORK(&net->xfrm.flow_cache_gc_work, flow_cache_gc_task);
^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: net-next: NULL pointer dereference on adding a net namespace and a system freeze
2014-03-10 14:04 ` Eric Dumazet
@ 2014-03-11 0:46 ` Jakub Kiciński
2014-03-11 5:30 ` Steffen Klassert
2014-03-11 12:00 ` Steffen Klassert
0 siblings, 2 replies; 21+ messages in thread
From: Jakub Kiciński @ 2014-03-11 0:46 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Fan Du, Steffen Klassert
On Mon, 10 Mar 2014 07:04:36 -0700, Eric Dumazet wrote:
> On Mon, 2014-03-10 at 13:19 +0100, Jakub Kiciński wrote:
>
> > It helps with the flow_cache warning and BUG ("ip netns add" works) but
> > machine still freezes after 5-10 minutes. I will try to revert
> > ca925cf1534ebcec332c08719a7dee6ee1782ce4 and see if that solves it.
>
> I think the other issue is separate. It might be triggered by
> conntracking change.
I bisected the other issue to be caused/uncovered by:
commit 1a1ccc96abb2ed9b8fbb71018e64b97324caef53
Author: Steffen Klassert <steffen.klassert@secunet.com>
Date: Wed Feb 19 10:07:34 2014 +0100
xfrm: Remove caching of xfrm_policy_sk_bundles
We currently cache socket policy bundles at xfrm_policy_sk_bundles.
These cached bundles are never used. Instead we create and cache
a new one whenever xfrm_lookup() is called on a socket policy.
Most protocols cache the used routes to the socket, so let's
remove the unused caching of socket policy bundles in xfrm.
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Machine freezes after FLOW_HASH_RND_PERIOD (default 10 minutes).
Now get this warning during boot:
[ 31.664820] ------------[ cut here ]------------
[ 31.664824] WARNING: CPU: 2 PID: 3560 at /home/kuba/Development/Linux/net-next/lib/list_debug.c:33 __list_add+0xac/0xc0()
[ 31.664826] list_add corruption. prev->next should be next (ffff880224579598), but was (null). (prev=ffff8802106140e8).
[ 31.664827] Modules linked in: xt_CHECKSUM tun bridge stp llc ccm xt_conntrack iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw ftdi_sio arc4 rt2800pci rt2800mmio rt2800lib crc_ccitt eeprom_93cx6 rt2x00pci kvm_amd rt2x00mmio rt2x00lib mac80211 kvm snd_ca0106 cfg80211 e1000e snd_ac97_codec ac97_bus microcode serio_raw ptp i2c_piix4 k10temp acpi_cpufreq pps_core wmi r8169 mii rfkill nfsd auth_rpcgss nfs_acl lockd binfmt_misc sunrpc usb_storage radeon drm_kms_helper ttm
[ 31.664855] CPU: 2 PID: 3560 Comm: (t-daemon) Not tainted 3.14.0-rc2-1a1ccc96abb2ed9b8fbb71018e64b97324caef53+ #11
[ 31.664856] Hardware name: Gigabyte Technology Co., Ltd. GA-MA790XT-UD4P/GA-MA790XT-UD4P, BIOS F9b 08/17/2012
[ 31.664857] 0000000000000009 ffff8802242e7c70 ffffffff81627878 ffff8802242e7cb8
[ 31.664859] ffff8802242e7ca8 ffffffff8104a28d ffff880210610ea8 ffff880224579598
[ 31.664861] ffff8802106140e8 ffff880224578000 0000000000000000 ffff8802242e7d08
[ 31.664863] Call Trace:
[ 31.664865] [<ffffffff81627878>] dump_stack+0x4d/0x66
[ 31.664867] [<ffffffff8104a28d>] warn_slowpath_common+0x7d/0xa0
[ 31.664869] [<ffffffff8104a2fc>] warn_slowpath_fmt+0x4c/0x50
[ 31.664871] [<ffffffff812fdd8c>] __list_add+0xac/0xc0
[ 31.664873] [<ffffffff81055d33>] __internal_add_timer+0x113/0x130
[ 31.664875] [<ffffffff81055f47>] internal_add_timer+0x17/0x40
[ 31.664876] [<ffffffff810587b2>] mod_timer+0x102/0x230
[ 31.664878] [<ffffffff810588f8>] add_timer+0x18/0x20
[ 31.664880] [<ffffffff81572204>] flow_cache_init+0x224/0x2b0
[ 31.664882] [<ffffffff815f7247>] xfrm_net_init+0x227/0x360
[ 31.664884] [<ffffffff815f7171>] ? xfrm_net_init+0x151/0x360
[ 31.664886] [<ffffffff81553131>] ops_init+0x41/0x150
[ 31.664888] [<ffffffff815532b3>] setup_net+0x73/0x110
[ 31.664890] [<ffffffff815537f2>] copy_net_ns+0x72/0x100
[ 31.664892] [<ffffffff81072619>] create_new_namespaces+0xf9/0x190
[ 31.664894] [<ffffffff81072891>] unshare_nsproxy_namespaces+0x61/0xa0
[ 31.664895] [<ffffffff81049949>] SyS_unshare+0x159/0x270
[ 31.664897] [<ffffffff81638092>] system_call_fastpath+0x16/0x1b
-- kuba
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH net-next] flowcache: restore a single flow_cache kmem_cache
2014-03-10 14:09 ` [PATCH net-next] flowcache: restore a single flow_cache kmem_cache Eric Dumazet
@ 2014-03-11 1:45 ` David Miller
0 siblings, 0 replies; 21+ messages in thread
From: David Miller @ 2014-03-11 1:45 UTC (permalink / raw)
To: eric.dumazet; +Cc: fan.du, moorray3, netdev, steffen.klassert
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 10 Mar 2014 07:09:07 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> It is not legal to create multiple kmem_cache having the same name.
>
> flowcache can use a single kmem_cache, no need for a per netns
> one.
>
> Fixes: ca925cf1534e ("flowcache: Make flow cache name space aware")
> Reported-by: Jakub Kicinski <moorray3@wp.pl>
> Tested-by: Jakub Kicinski <moorray3@wp.pl>
> Tested-by: Fan Du <fan.du@windriver.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
I'll apply this directly to net-next, thanks Eric!
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: net-next: NULL pointer dereference on adding a net namespace and a system freeze
2014-03-11 0:46 ` Jakub Kiciński
@ 2014-03-11 5:30 ` Steffen Klassert
2014-03-11 12:00 ` Steffen Klassert
1 sibling, 0 replies; 21+ messages in thread
From: Steffen Klassert @ 2014-03-11 5:30 UTC (permalink / raw)
To: Jakub Kiciński; +Cc: Eric Dumazet, netdev, Fan Du
On Tue, Mar 11, 2014 at 01:46:49AM +0100, Jakub Kiciński wrote:
> On Mon, 10 Mar 2014 07:04:36 -0700, Eric Dumazet wrote:
> > On Mon, 2014-03-10 at 13:19 +0100, Jakub Kiciński wrote:
> >
> > > It helps with the flow_cache warning and BUG ("ip netns add" works) but
> > > machine still freezes after 5-10 minutes. I will try to revert
> > > ca925cf1534ebcec332c08719a7dee6ee1782ce4 and see if that solves it.
> >
> > I think the other issue is separate. It might be triggered by
> > conntracking change.
>
> I bisected the other issue to be caused/uncovered by:
>
> commit 1a1ccc96abb2ed9b8fbb71018e64b97324caef53
> Author: Steffen Klassert <steffen.klassert@secunet.com>
> Date: Wed Feb 19 10:07:34 2014 +0100
>
> xfrm: Remove caching of xfrm_policy_sk_bundles
>
> We currently cache socket policy bundles at xfrm_policy_sk_bundles.
> These cached bundles are never used. Instead we create and cache
> a new one whenever xfrm_lookup() is called on a socket policy.
>
> Most protocols cache the used routes to the socket, so let's
> remove the unused caching of socket policy bundles in xfrm.
>
> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
>
>
> Machine freezes after FLOW_HASH_RND_PERIOD (default 10 minutes).
Hm, I used this for more than a month before I pushed it upstream.
But this was without the flowcache namespace changes, maybe this
interferes with the flowcache namespace changes.
I'll look into it, thanks for reporting and bisecting!
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: net-next: NULL pointer dereference on adding a net namespace and a system freeze
2014-03-11 0:46 ` Jakub Kiciński
2014-03-11 5:30 ` Steffen Klassert
@ 2014-03-11 12:00 ` Steffen Klassert
2014-03-11 12:40 ` Eric Dumazet
` (2 more replies)
1 sibling, 3 replies; 21+ messages in thread
From: Steffen Klassert @ 2014-03-11 12:00 UTC (permalink / raw)
To: Jakub Kiciński; +Cc: Eric Dumazet, netdev, Fan Du
On Tue, Mar 11, 2014 at 01:46:49AM +0100, Jakub Kiciński wrote:
>
> I bisected the other issue to be caused/uncovered by:
>
> commit 1a1ccc96abb2ed9b8fbb71018e64b97324caef53
> Author: Steffen Klassert <steffen.klassert@secunet.com>
> Date: Wed Feb 19 10:07:34 2014 +0100
>
> xfrm: Remove caching of xfrm_policy_sk_bundles
>
> We currently cache socket policy bundles at xfrm_policy_sk_bundles.
> These cached bundles are never used. Instead we create and cache
> a new one whenever xfrm_lookup() is called on a socket policy.
>
> Most protocols cache the used routes to the socket, so let's
> remove the unused caching of socket policy bundles in xfrm.
>
> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
>
This patch should affect only on the usage of IPsec socket policies.
Do you use socket policies, or do you use IPsec at all?
>
> Machine freezes after FLOW_HASH_RND_PERIOD (default 10 minutes).
> Now get this warning during boot:
>
> [ 31.664820] ------------[ cut here ]------------
> [ 31.664824] WARNING: CPU: 2 PID: 3560 at /home/kuba/Development/Linux/net-next/lib/list_debug.c:33 __list_add+0xac/0xc0()
> [ 31.664826] list_add corruption. prev->next should be next (ffff880224579598), but was (null). (prev=ffff8802106140e8).
> [ 31.664827] Modules linked in: xt_CHECKSUM tun bridge stp llc ccm xt_conntrack iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw ftdi_sio arc4 rt2800pci rt2800mmio rt2800lib crc_ccitt eeprom_93cx6 rt2x00pci kvm_amd rt2x00mmio rt2x00lib mac80211 kvm snd_ca0106 cfg80211 e1000e snd_ac97_codec ac97_bus microcode serio_raw ptp i2c_piix4 k10temp acpi_cpufreq pps_core wmi r8169 mii rfkill nfsd auth_rpcgss nfs_acl lockd binfmt_misc sunrpc usb_storage radeon drm_kms_helper ttm
> [ 31.664855] CPU: 2 PID: 3560 Comm: (t-daemon) Not tainted 3.14.0-rc2-1a1ccc96abb2ed9b8fbb71018e64b97324caef53+ #11
> [ 31.664856] Hardware name: Gigabyte Technology Co., Ltd. GA-MA790XT-UD4P/GA-MA790XT-UD4P, BIOS F9b 08/17/2012
> [ 31.664857] 0000000000000009 ffff8802242e7c70 ffffffff81627878 ffff8802242e7cb8
> [ 31.664859] ffff8802242e7ca8 ffffffff8104a28d ffff880210610ea8 ffff880224579598
> [ 31.664861] ffff8802106140e8 ffff880224578000 0000000000000000 ffff8802242e7d08
> [ 31.664863] Call Trace:
> [ 31.664865] [<ffffffff81627878>] dump_stack+0x4d/0x66
> [ 31.664867] [<ffffffff8104a28d>] warn_slowpath_common+0x7d/0xa0
> [ 31.664869] [<ffffffff8104a2fc>] warn_slowpath_fmt+0x4c/0x50
> [ 31.664871] [<ffffffff812fdd8c>] __list_add+0xac/0xc0
> [ 31.664873] [<ffffffff81055d33>] __internal_add_timer+0x113/0x130
> [ 31.664875] [<ffffffff81055f47>] internal_add_timer+0x17/0x40
> [ 31.664876] [<ffffffff810587b2>] mod_timer+0x102/0x230
> [ 31.664878] [<ffffffff810588f8>] add_timer+0x18/0x20
> [ 31.664880] [<ffffffff81572204>] flow_cache_init+0x224/0x2b0
> [ 31.664882] [<ffffffff815f7247>] xfrm_net_init+0x227/0x360
> [ 31.664884] [<ffffffff815f7171>] ? xfrm_net_init+0x151/0x360
> [ 31.664886] [<ffffffff81553131>] ops_init+0x41/0x150
> [ 31.664888] [<ffffffff815532b3>] setup_net+0x73/0x110
> [ 31.664890] [<ffffffff815537f2>] copy_net_ns+0x72/0x100
> [ 31.664892] [<ffffffff81072619>] create_new_namespaces+0xf9/0x190
> [ 31.664894] [<ffffffff81072891>] unshare_nsproxy_namespaces+0x61/0xa0
> [ 31.664895] [<ffffffff81049949>] SyS_unshare+0x159/0x270
> [ 31.664897] [<ffffffff81638092>] system_call_fastpath+0x16/0x1b
>
I was unable to reproduce this here, but it looks like the flowcache
namespace changes are still not complete. We leak an active timer
and all the allocated resources when we exit a namespace.
Could you please try the patch below?
Also, please send your config if the patch does not fix your problem.
Thanks!
---
include/net/flow.h | 1 +
net/core/flow.c | 18 ++++++++++++++++++
net/xfrm/xfrm_policy.c | 7 ++++++-
3 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/include/net/flow.h b/include/net/flow.h
index bee3741..64fd248 100644
--- a/include/net/flow.h
+++ b/include/net/flow.h
@@ -219,6 +219,7 @@ struct flow_cache_object *flow_cache_lookup(struct net *net,
u8 dir, flow_resolve_t resolver,
void *ctx);
int flow_cache_init(struct net *net);
+void flow_cache_fini(struct net *net);
void flow_cache_flush(struct net *net);
void flow_cache_flush_deferred(struct net *net);
diff --git a/net/core/flow.c b/net/core/flow.c
index 102f8ea..d31c3c4 100644
--- a/net/core/flow.c
+++ b/net/core/flow.c
@@ -484,3 +484,21 @@ err:
return -ENOMEM;
}
EXPORT_SYMBOL(flow_cache_init);
+
+void flow_cache_fini(struct net *net)
+{
+ int i;
+ struct flow_cache *fc = &net->xfrm.flow_cache_global;
+
+ del_timer(&fc->rnd_timer);
+
+ for_each_possible_cpu(i) {
+ struct flow_cache_percpu *fcp = per_cpu_ptr(fc->percpu, i);
+ kfree(fcp->hash_table);
+ fcp->hash_table = NULL;
+ }
+
+ free_percpu(fc->percpu);
+ fc->percpu = NULL;
+}
+EXPORT_SYMBOL(flow_cache_fini);
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index a75fae4..f02f511 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -2913,15 +2913,19 @@ static int __net_init xfrm_net_init(struct net *net)
rv = xfrm_sysctl_init(net);
if (rv < 0)
goto out_sysctl;
+ rv = flow_cache_init(net);
+ if (rv < 0)
+ goto out;
/* Initialize the per-net locks here */
spin_lock_init(&net->xfrm.xfrm_state_lock);
rwlock_init(&net->xfrm.xfrm_policy_lock);
mutex_init(&net->xfrm.xfrm_cfg_mutex);
- flow_cache_init(net);
return 0;
+out:
+ xfrm_sysctl_fini(net);
out_sysctl:
xfrm_policy_fini(net);
out_policy:
@@ -2934,6 +2938,7 @@ out_statistics:
static void __net_exit xfrm_net_exit(struct net *net)
{
+ flow_cache_fini(net);
xfrm_sysctl_fini(net);
xfrm_policy_fini(net);
xfrm_state_fini(net);
--
1.7.9.5
^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: net-next: NULL pointer dereference on adding a net namespace and a system freeze
2014-03-11 12:00 ` Steffen Klassert
@ 2014-03-11 12:40 ` Eric Dumazet
2014-03-11 13:20 ` Steffen Klassert
2014-03-11 12:42 ` net-next: NULL pointer dereference on adding a net namespace and a system freeze Jakub Kiciński
2014-03-12 10:02 ` Fan Du
2 siblings, 1 reply; 21+ messages in thread
From: Eric Dumazet @ 2014-03-11 12:40 UTC (permalink / raw)
To: Steffen Klassert; +Cc: Jakub Kiciński, netdev, Fan Du
On Tue, 2014-03-11 at 13:00 +0100, Steffen Klassert wrote:
> I was unable to reproduce this here, but it looks like the flowcache
> namespace changes are still not complete. We leak an active timer
> and all the allocated resources when we exit a namespace.
>
> Could you please try the patch below?
>
> Also, please send your config if the patch does not fix your problem.
>
> Thanks!
>
> ---
> include/net/flow.h | 1 +
> net/core/flow.c | 18 ++++++++++++++++++
> net/xfrm/xfrm_policy.c | 7 ++++++-
> 3 files changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/include/net/flow.h b/include/net/flow.h
> index bee3741..64fd248 100644
> --- a/include/net/flow.h
> +++ b/include/net/flow.h
> @@ -219,6 +219,7 @@ struct flow_cache_object *flow_cache_lookup(struct net *net,
> u8 dir, flow_resolve_t resolver,
> void *ctx);
> int flow_cache_init(struct net *net);
> +void flow_cache_fini(struct net *net);
>
> void flow_cache_flush(struct net *net);
> void flow_cache_flush_deferred(struct net *net);
> diff --git a/net/core/flow.c b/net/core/flow.c
> index 102f8ea..d31c3c4 100644
> --- a/net/core/flow.c
> +++ b/net/core/flow.c
> @@ -484,3 +484,21 @@ err:
> return -ENOMEM;
> }
> EXPORT_SYMBOL(flow_cache_init);
> +
> +void flow_cache_fini(struct net *net)
> +{
> + int i;
> + struct flow_cache *fc = &net->xfrm.flow_cache_global;
> +
> + del_timer(&fc->rnd_timer);
del_timer_sync() I guess is better.
> +
> + for_each_possible_cpu(i) {
> + struct flow_cache_percpu *fcp = per_cpu_ptr(fc->percpu, i);
> + kfree(fcp->hash_table);
> + fcp->hash_table = NULL;
> + }
> +
> + free_percpu(fc->percpu);
> + fc->percpu = NULL;
> +}
> +EXPORT_SYMBOL(flow_cache_fini);
> diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
> index a75fae4..f02f511 100644
> --- a/net/xfrm/xfrm_policy.c
> +++ b/net/xfrm/xfrm_policy.c
> @@ -2913,15 +2913,19 @@ static int __net_init xfrm_net_init(struct net *net)
> rv = xfrm_sysctl_init(net);
> if (rv < 0)
> goto out_sysctl;
> + rv = flow_cache_init(net);
> + if (rv < 0)
> + goto out;
>
> /* Initialize the per-net locks here */
> spin_lock_init(&net->xfrm.xfrm_state_lock);
> rwlock_init(&net->xfrm.xfrm_policy_lock);
> mutex_init(&net->xfrm.xfrm_cfg_mutex);
>
> - flow_cache_init(net);
> return 0;
>
> +out:
> + xfrm_sysctl_fini(net);
> out_sysctl:
> xfrm_policy_fini(net);
> out_policy:
> @@ -2934,6 +2938,7 @@ out_statistics:
>
> static void __net_exit xfrm_net_exit(struct net *net)
> {
> + flow_cache_fini(net);
> xfrm_sysctl_fini(net);
> xfrm_policy_fini(net);
> xfrm_state_fini(net);
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: net-next: NULL pointer dereference on adding a net namespace and a system freeze
2014-03-11 12:00 ` Steffen Klassert
2014-03-11 12:40 ` Eric Dumazet
@ 2014-03-11 12:42 ` Jakub Kiciński
2014-03-12 10:02 ` Fan Du
2 siblings, 0 replies; 21+ messages in thread
From: Jakub Kiciński @ 2014-03-11 12:42 UTC (permalink / raw)
To: Steffen Klassert; +Cc: Eric Dumazet, netdev, Fan Du
On Tue, 11 Mar 2014 13:00:59 +0100, Steffen Klassert wrote:
> On Tue, Mar 11, 2014 at 01:46:49AM +0100, Jakub Kiciński wrote:
> >
> > I bisected the other issue to be caused/uncovered by:
> >
> > commit 1a1ccc96abb2ed9b8fbb71018e64b97324caef53
> > Author: Steffen Klassert <steffen.klassert@secunet.com>
> > Date: Wed Feb 19 10:07:34 2014 +0100
> >
> > xfrm: Remove caching of xfrm_policy_sk_bundles
> >
> > We currently cache socket policy bundles at xfrm_policy_sk_bundles.
> > These cached bundles are never used. Instead we create and cache
> > a new one whenever xfrm_lookup() is called on a socket policy.
> >
> > Most protocols cache the used routes to the socket, so let's
> > remove the unused caching of socket policy bundles in xfrm.
> >
> > Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
> >
>
> This patch should affect only on the usage of IPsec socket policies.
> Do you use socket policies, or do you use IPsec at all?
I'm running pretty standard Fedora 20 installation here (notably with
NetowrkManager removed). Two daemons that trigger flow_cache warnings
are libvirt and rtkit.
I'm not sure how to check IPsec policies, ip xfrm state/policy don't
show anything.
> >
> > Machine freezes after FLOW_HASH_RND_PERIOD (default 10 minutes).
> > Now get this warning during boot:
> >
> > [ 31.664820] ------------[ cut here ]------------
> > [ 31.664824] WARNING: CPU: 2 PID: 3560 at /home/kuba/Development/Linux/net-next/lib/list_debug.c:33 __list_add+0xac/0xc0()
> > [ 31.664826] list_add corruption. prev->next should be next (ffff880224579598), but was (null). (prev=ffff8802106140e8).
> > [ 31.664827] Modules linked in: xt_CHECKSUM tun bridge stp llc ccm xt_conntrack iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw ftdi_sio arc4 rt2800pci rt2800mmio rt2800lib crc_ccitt eeprom_93cx6 rt2x00pci kvm_amd rt2x00mmio rt2x00lib mac80211 kvm snd_ca0106 cfg80211 e1000e snd_ac97_codec ac97_bus microcode serio_raw ptp i2c_piix4 k10temp acpi_cpufreq pps_core wmi r8169 mii rfkill nfsd auth_rpcgss nfs_acl lockd binfmt_misc sunrpc usb_storage radeon drm_kms_helper ttm
> > [ 31.664855] CPU: 2 PID: 3560 Comm: (t-daemon) Not tainted 3.14.0-rc2-1a1ccc96abb2ed9b8fbb71018e64b97324caef53+ #11
> > [ 31.664856] Hardware name: Gigabyte Technology Co., Ltd. GA-MA790XT-UD4P/GA-MA790XT-UD4P, BIOS F9b 08/17/2012
> > [ 31.664857] 0000000000000009 ffff8802242e7c70 ffffffff81627878 ffff8802242e7cb8
> > [ 31.664859] ffff8802242e7ca8 ffffffff8104a28d ffff880210610ea8 ffff880224579598
> > [ 31.664861] ffff8802106140e8 ffff880224578000 0000000000000000 ffff8802242e7d08
> > [ 31.664863] Call Trace:
> > [ 31.664865] [<ffffffff81627878>] dump_stack+0x4d/0x66
> > [ 31.664867] [<ffffffff8104a28d>] warn_slowpath_common+0x7d/0xa0
> > [ 31.664869] [<ffffffff8104a2fc>] warn_slowpath_fmt+0x4c/0x50
> > [ 31.664871] [<ffffffff812fdd8c>] __list_add+0xac/0xc0
> > [ 31.664873] [<ffffffff81055d33>] __internal_add_timer+0x113/0x130
> > [ 31.664875] [<ffffffff81055f47>] internal_add_timer+0x17/0x40
> > [ 31.664876] [<ffffffff810587b2>] mod_timer+0x102/0x230
> > [ 31.664878] [<ffffffff810588f8>] add_timer+0x18/0x20
> > [ 31.664880] [<ffffffff81572204>] flow_cache_init+0x224/0x2b0
> > [ 31.664882] [<ffffffff815f7247>] xfrm_net_init+0x227/0x360
> > [ 31.664884] [<ffffffff815f7171>] ? xfrm_net_init+0x151/0x360
> > [ 31.664886] [<ffffffff81553131>] ops_init+0x41/0x150
> > [ 31.664888] [<ffffffff815532b3>] setup_net+0x73/0x110
> > [ 31.664890] [<ffffffff815537f2>] copy_net_ns+0x72/0x100
> > [ 31.664892] [<ffffffff81072619>] create_new_namespaces+0xf9/0x190
> > [ 31.664894] [<ffffffff81072891>] unshare_nsproxy_namespaces+0x61/0xa0
> > [ 31.664895] [<ffffffff81049949>] SyS_unshare+0x159/0x270
> > [ 31.664897] [<ffffffff81638092>] system_call_fastpath+0x16/0x1b
> >
>
> I was unable to reproduce this here, but it looks like the flowcache
> namespace changes are still not complete. We leak an active timer
> and all the allocated resources when we exit a namespace.
I also failed to reproduce it reliably on a VM. On a VM it happens 50%
of the times while on physical machine it's triggered reliably on every
boot.
While playing restarting libvirt and rtkit to see it they produce any
xfrm noise I got this:
[ 292.624771] BUG: soft lockup - CPU#1 stuck for 22s! [(t-daemon):4655]
[ 292.624777] Modules linked in: bnep bluetooth 6lowpan_iphc fuse ipt_MASQUERADE xt_CHECKSUM tun bridge stp llc ccm xt_conntrack iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw arc4 rt2800pci rt2800mmio rt2800lib crc_ccitt eeprom_93cx6 rt2x00pci rt2x00mmio rt2x00lib ftdi_sio kvm_amd mac80211 cfg80211 kvm e1000e snd_ca0106 snd_ac97_codec i2c_piix4 rfkill microcode ac97_bus serio_raw k10temp r8169 mii acpi_cpufreq ptp wmi pps_core nfsd auth_rpcgss nfs_acl lockd binfmt_misc sunrpc usb_storage radeon drm_kms_helper ttm
[ 292.624884] CPU: 1 PID: 4655 Comm: (t-daemon) Not tainted 3.14.0-rc2d3623099d3509fa68fa28235366049dd3156c63a+ #10
[ 292.624889] Hardware name: Gigabyte Technology Co., Ltd. GA-MA790XT-UD4P/GA-MA790XT-UD4P, BIOS F9b 08/17/2012
[ 292.624894] task: ffff8802228753c0 ti: ffff8800b515a000 task.ti: ffff8800b515a000
[ 292.624899] RIP: 0010:[<ffffffff81072a63>] [<ffffffff81072a63>] raw_notifier_chain_register+0x23/0x40
[ 292.624910] RSP: 0018:ffff8800b515bd98 EFLAGS: 00000246
[ 292.624914] RAX: ffff8802014d0ec0 RBX: ffffffff81c23340 RCX: 0000000000000004
[ 292.624919] RDX: 0000000000000000 RSI: ffff8800b50f1fc0 RDI: ffff8802014d0ec8
[ 292.624923] RBP: ffff8800b515bd98 R08: 0000000000000000 R09: 0000000000000000
[ 292.624928] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff81c233a8
[ 292.624933] R13: 0000000180040004 R14: 0000000000000246 R15: 000060fd00000000
[ 292.624939] FS: 00007fa39d6118c0(0000) GS:ffff88022fc80000(0000) knlGS:00000000e26ffb40
[ 292.624944] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 292.624948] CR2: 00007fa4b45a7f40 CR3: 00000000bd2e6000 CR4: 00000000000007e0
[ 292.624951] Stack:
[ 292.624955] ffff8800b515bdb0 ffffffff8161ff8a ffff8800b50f1100 ffff8800b515bde0
[ 292.624965] ffffffff815721be ffff8800b50f1100 0000000000000000 ffff8800b50f1160
[ 292.624974] ffff8800b50f1290 ffff8800b515be28 ffffffff815f7321 ffffffff815f7231
[ 292.624982] Call Trace:
[ 292.624992] [<ffffffff8161ff8a>] register_cpu_notifier+0x2a/0x40
[ 292.625001] [<ffffffff815721be>] flow_cache_init+0x1de/0x2b0
[ 292.625009] [<ffffffff815f7321>] xfrm_net_init+0x241/0x380
[ 292.625016] [<ffffffff815f7231>] ? xfrm_net_init+0x151/0x380
[ 292.625025] [<ffffffff81553131>] ops_init+0x41/0x150
[ 292.625033] [<ffffffff815532b3>] setup_net+0x73/0x110
[ 292.625042] [<ffffffff815537f2>] copy_net_ns+0x72/0x100
[ 292.625050] [<ffffffff81072619>] create_new_namespaces+0xf9/0x190
[ 292.625058] [<ffffffff81072891>] unshare_nsproxy_namespaces+0x61/0xa0
[ 292.625065] [<ffffffff81049949>] SyS_unshare+0x159/0x270
[ 292.625073] [<ffffffff816381d2>] system_call_fastpath+0x16/0x1b
[ 292.625077] Code: e9 7b ff ff ff 0f 1f 00 66 66 66 66 90 55 48 8b 07 48 89 e5 48 85 c0 74 21 8b 56 10 3b 50 10 7e 0c eb 17 0f 1f 44 00 00 39 50 10 <7c> 0d 48 8d 78 08 48 8b 40 08 48 85 c0 75 ee 48 89 46 08 31 c0
This is net-next with head at d3623099d3509fa68fa28235366049dd3156c63a
It takes a few restarts of libvirt/rtkit-daemon to trigger, but I've
definitely seen register_cpu_notifier appearing in backtraces before...
maybe this is some kind of a lead?
> Could you please try the patch below?
Testing now... Expect results in 15 minutes...
> Also, please send your config if the patch does not fix your problem.
config: http://paste.fedoraproject.org/84281/54146313
-- kuba
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: net-next: NULL pointer dereference on adding a net namespace and a system freeze
2014-03-11 12:40 ` Eric Dumazet
@ 2014-03-11 13:20 ` Steffen Klassert
2014-03-11 14:30 ` Jakub Kiciński
0 siblings, 1 reply; 21+ messages in thread
From: Steffen Klassert @ 2014-03-11 13:20 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Jakub Kiciński, netdev, Fan Du
On Tue, Mar 11, 2014 at 05:40:26AM -0700, Eric Dumazet wrote:
> On Tue, 2014-03-11 at 13:00 +0100, Steffen Klassert wrote:
>
> > I was unable to reproduce this here, but it looks like the flowcache
> > namespace changes are still not complete. We leak an active timer
> > and all the allocated resources when we exit a namespace.
> >
> > Could you please try the patch below?
> >
> > Also, please send your config if the patch does not fix your problem.
> >
> > Thanks!
> >
> > ---
> > include/net/flow.h | 1 +
> > net/core/flow.c | 18 ++++++++++++++++++
> > net/xfrm/xfrm_policy.c | 7 ++++++-
> > 3 files changed, 25 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/net/flow.h b/include/net/flow.h
> > index bee3741..64fd248 100644
> > --- a/include/net/flow.h
> > +++ b/include/net/flow.h
> > @@ -219,6 +219,7 @@ struct flow_cache_object *flow_cache_lookup(struct net *net,
> > u8 dir, flow_resolve_t resolver,
> > void *ctx);
> > int flow_cache_init(struct net *net);
> > +void flow_cache_fini(struct net *net);
> >
> > void flow_cache_flush(struct net *net);
> > void flow_cache_flush_deferred(struct net *net);
> > diff --git a/net/core/flow.c b/net/core/flow.c
> > index 102f8ea..d31c3c4 100644
> > --- a/net/core/flow.c
> > +++ b/net/core/flow.c
> > @@ -484,3 +484,21 @@ err:
> > return -ENOMEM;
> > }
> > EXPORT_SYMBOL(flow_cache_init);
> > +
> > +void flow_cache_fini(struct net *net)
> > +{
> > + int i;
> > + struct flow_cache *fc = &net->xfrm.flow_cache_global;
> > +
> > + del_timer(&fc->rnd_timer);
>
>
> del_timer_sync() I guess is better.
>
Right.
I've just noticed that I also forgot to do a
unregister_hotcpu_notifier(&fc->hotcpu_notifier).
Will update the next version according to that.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: net-next: NULL pointer dereference on adding a net namespace and a system freeze
2014-03-11 13:20 ` Steffen Klassert
@ 2014-03-11 14:30 ` Jakub Kiciński
2014-03-12 8:38 ` Steffen Klassert
0 siblings, 1 reply; 21+ messages in thread
From: Jakub Kiciński @ 2014-03-11 14:30 UTC (permalink / raw)
To: Steffen Klassert; +Cc: Eric Dumazet, netdev, Fan Du
On Tue, 11 Mar 2014 14:20:30 +0100, Steffen Klassert wrote:
> On Tue, Mar 11, 2014 at 05:40:26AM -0700, Eric Dumazet wrote:
> > On Tue, 2014-03-11 at 13:00 +0100, Steffen Klassert wrote:
> >
> > > I was unable to reproduce this here, but it looks like the flowcache
> > > namespace changes are still not complete. We leak an active timer
> > > and all the allocated resources when we exit a namespace.
> > >
> > > Could you please try the patch below?
> > >
> > > Also, please send your config if the patch does not fix your problem.
> > >
> > > Thanks!
> > >
> > > ---
> > > include/net/flow.h | 1 +
> > > net/core/flow.c | 18 ++++++++++++++++++
> > > net/xfrm/xfrm_policy.c | 7 ++++++-
> > > 3 files changed, 25 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/include/net/flow.h b/include/net/flow.h
> > > index bee3741..64fd248 100644
> > > --- a/include/net/flow.h
> > > +++ b/include/net/flow.h
> > > @@ -219,6 +219,7 @@ struct flow_cache_object *flow_cache_lookup(struct net *net,
> > > u8 dir, flow_resolve_t resolver,
> > > void *ctx);
> > > int flow_cache_init(struct net *net);
> > > +void flow_cache_fini(struct net *net);
> > >
> > > void flow_cache_flush(struct net *net);
> > > void flow_cache_flush_deferred(struct net *net);
> > > diff --git a/net/core/flow.c b/net/core/flow.c
> > > index 102f8ea..d31c3c4 100644
> > > --- a/net/core/flow.c
> > > +++ b/net/core/flow.c
> > > @@ -484,3 +484,21 @@ err:
> > > return -ENOMEM;
> > > }
> > > EXPORT_SYMBOL(flow_cache_init);
> > > +
> > > +void flow_cache_fini(struct net *net)
> > > +{
> > > + int i;
> > > + struct flow_cache *fc = &net->xfrm.flow_cache_global;
> > > +
> > > + del_timer(&fc->rnd_timer);
> >
> >
> > del_timer_sync() I guess is better.
> >
>
> Right.
>
> I've just noticed that I also forgot to do a
> unregister_hotcpu_notifier(&fc->hotcpu_notifier).
>
> Will update the next version according to that.
Tested with del_timer_sync and unregister_hotcpu_notifier:
void flow_cache_fini(struct net *net)
{
int i;
struct flow_cache *fc = &net->xfrm.flow_cache_global;
unregister_hotcpu_notifier(&fc->hotcpu_notifier);
del_timer_sync(&fc->rnd_timer);
for_each_possible_cpu(i) {
struct flow_cache_percpu *fcp = per_cpu_ptr(fc->percpu, i);
kfree(fcp->hash_table);
fcp->hash_table = NULL;
}
free_percpu(fc->percpu);
fc->percpu = NULL;
}
EXPORT_SYMBOL(flow_cache_fini);
Seems to solve both the freeze and the bug on restarting libvirtd/rtkit!
-- kuba
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: net-next: NULL pointer dereference on adding a net namespace and a system freeze
2014-03-11 14:30 ` Jakub Kiciński
@ 2014-03-12 8:38 ` Steffen Klassert
2014-03-12 8:43 ` [PATCH net-next] flowcache: Fix resource leaks on namespace exit Steffen Klassert
0 siblings, 1 reply; 21+ messages in thread
From: Steffen Klassert @ 2014-03-12 8:38 UTC (permalink / raw)
To: Jakub Kiciński; +Cc: Eric Dumazet, netdev, Fan Du
On Tue, Mar 11, 2014 at 03:30:29PM +0100, Jakub Kiciński wrote:
>
> Tested with del_timer_sync and unregister_hotcpu_notifier:
>
> void flow_cache_fini(struct net *net)
> {
> int i;
> struct flow_cache *fc = &net->xfrm.flow_cache_global;
>
> unregister_hotcpu_notifier(&fc->hotcpu_notifier);
> del_timer_sync(&fc->rnd_timer);
>
> for_each_possible_cpu(i) {
> struct flow_cache_percpu *fcp = per_cpu_ptr(fc->percpu, i);
> kfree(fcp->hash_table);
> fcp->hash_table = NULL;
> }
>
> free_percpu(fc->percpu);
> fc->percpu = NULL;
> }
> EXPORT_SYMBOL(flow_cache_fini);
>
>
> Seems to solve both the freeze and the bug on restarting libvirtd/rtkit!
>
Thanks a lot for testing!
I'll submit the updated patch now.
^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH net-next] flowcache: Fix resource leaks on namespace exit.
2014-03-12 8:38 ` Steffen Klassert
@ 2014-03-12 8:43 ` Steffen Klassert
2014-03-12 11:43 ` Eric Dumazet
2014-03-12 19:31 ` David Miller
0 siblings, 2 replies; 21+ messages in thread
From: Steffen Klassert @ 2014-03-12 8:43 UTC (permalink / raw)
To: Jakub Kiciński, David Miller; +Cc: Eric Dumazet, netdev, Fan Du
We leak an active timer, the hotcpu notifier and all allocated
resources when we exit a namespace. Fix this by introducing a
flow_cache_fini() function where we release the resources before
we exit.
Fixes: ca925cf1534e ("flowcache: Make flow cache name space aware")
Reported-by: Jakub Kicinski <moorray3@wp.pl>
Tested-by: Jakub Kicinski <moorray3@wp.pl>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Fan Du <fan.du@windriver.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
include/net/flow.h | 1 +
net/core/flow.c | 19 +++++++++++++++++++
net/xfrm/xfrm_policy.c | 7 ++++++-
3 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/include/net/flow.h b/include/net/flow.h
index bee3741..64fd248 100644
--- a/include/net/flow.h
+++ b/include/net/flow.h
@@ -219,6 +219,7 @@ struct flow_cache_object *flow_cache_lookup(struct net *net,
u8 dir, flow_resolve_t resolver,
void *ctx);
int flow_cache_init(struct net *net);
+void flow_cache_fini(struct net *net);
void flow_cache_flush(struct net *net);
void flow_cache_flush_deferred(struct net *net);
diff --git a/net/core/flow.c b/net/core/flow.c
index 102f8ea..31cfb36 100644
--- a/net/core/flow.c
+++ b/net/core/flow.c
@@ -484,3 +484,22 @@ err:
return -ENOMEM;
}
EXPORT_SYMBOL(flow_cache_init);
+
+void flow_cache_fini(struct net *net)
+{
+ int i;
+ struct flow_cache *fc = &net->xfrm.flow_cache_global;
+
+ del_timer_sync(&fc->rnd_timer);
+ unregister_hotcpu_notifier(&fc->hotcpu_notifier);
+
+ for_each_possible_cpu(i) {
+ struct flow_cache_percpu *fcp = per_cpu_ptr(fc->percpu, i);
+ kfree(fcp->hash_table);
+ fcp->hash_table = NULL;
+ }
+
+ free_percpu(fc->percpu);
+ fc->percpu = NULL;
+}
+EXPORT_SYMBOL(flow_cache_fini);
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index a75fae4..f02f511 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -2913,15 +2913,19 @@ static int __net_init xfrm_net_init(struct net *net)
rv = xfrm_sysctl_init(net);
if (rv < 0)
goto out_sysctl;
+ rv = flow_cache_init(net);
+ if (rv < 0)
+ goto out;
/* Initialize the per-net locks here */
spin_lock_init(&net->xfrm.xfrm_state_lock);
rwlock_init(&net->xfrm.xfrm_policy_lock);
mutex_init(&net->xfrm.xfrm_cfg_mutex);
- flow_cache_init(net);
return 0;
+out:
+ xfrm_sysctl_fini(net);
out_sysctl:
xfrm_policy_fini(net);
out_policy:
@@ -2934,6 +2938,7 @@ out_statistics:
static void __net_exit xfrm_net_exit(struct net *net)
{
+ flow_cache_fini(net);
xfrm_sysctl_fini(net);
xfrm_policy_fini(net);
xfrm_state_fini(net);
--
1.7.9.5
^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: net-next: NULL pointer dereference on adding a net namespace and a system freeze
2014-03-11 12:00 ` Steffen Klassert
2014-03-11 12:40 ` Eric Dumazet
2014-03-11 12:42 ` net-next: NULL pointer dereference on adding a net namespace and a system freeze Jakub Kiciński
@ 2014-03-12 10:02 ` Fan Du
2 siblings, 0 replies; 21+ messages in thread
From: Fan Du @ 2014-03-12 10:02 UTC (permalink / raw)
To: Steffen Klassert; +Cc: Jakub Kiciński, Eric Dumazet, netdev
On 2014年03月11日 20:00, Steffen Klassert wrote:
> On Tue, Mar 11, 2014 at 01:46:49AM +0100, Jakub Kiciński wrote:
>> >
>> > I bisected the other issue to be caused/uncovered by:
>> >
>> > commit 1a1ccc96abb2ed9b8fbb71018e64b97324caef53
>> > Author: Steffen Klassert<steffen.klassert@secunet.com>
>> > Date: Wed Feb 19 10:07:34 2014 +0100
>> >
>> > xfrm: Remove caching of xfrm_policy_sk_bundles
>> >
>> > We currently cache socket policy bundles at xfrm_policy_sk_bundles.
>> > These cached bundles are never used. Instead we create and cache
>> > a new one whenever xfrm_lookup() is called on a socket policy.
>> >
>> > Most protocols cache the used routes to the socket, so let's
>> > remove the unused caching of socket policy bundles in xfrm.
>> >
>> > Signed-off-by: Steffen Klassert<steffen.klassert@secunet.com>
>> >
> This patch should affect only on the usage of IPsec socket policies.
> Do you use socket policies, or do you use IPsec at all?
>
>> >
>> > Machine freezes after FLOW_HASH_RND_PERIOD (default 10 minutes).
>> > Now get this warning during boot:
>> >
>> > [ 31.664820] ------------[ cut here ]------------
>> > [ 31.664824] WARNING: CPU: 2 PID: 3560 at /home/kuba/Development/Linux/net-next/lib/list_debug.c:33 __list_add+0xac/0xc0()
>> > [ 31.664826] list_add corruption. prev->next should be next (ffff880224579598), but was (null). (prev=ffff8802106140e8).
>> > [ 31.664827] Modules linked in: xt_CHECKSUM tun bridge stp llc ccm xt_conntrack iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw ftdi_sio arc4 rt2800pci rt2800mmio rt2800lib crc_ccitt eeprom_93cx6 rt2x00pci kvm_amd rt2x00mmio rt2x00lib mac80211 kvm snd_ca0106 cfg80211 e1000e snd_ac97_codec ac97_bus microcode serio_raw ptp i2c_piix4 k10temp acpi_cpufreq pps_core wmi r8169 mii rfkill nfsd auth_rpcgss nfs_acl lockd binfmt_misc sunrpc usb_storage radeon drm_kms_helper ttm
>> > [ 31.664855] CPU: 2 PID: 3560 Comm: (t-daemon) Not tainted 3.14.0-rc2-1a1ccc96abb2ed9b8fbb71018e64b97324caef53+ #11
>> > [ 31.664856] Hardware name: Gigabyte Technology Co., Ltd. GA-MA790XT-UD4P/GA-MA790XT-UD4P, BIOS F9b 08/17/2012
>> > [ 31.664857] 0000000000000009 ffff8802242e7c70 ffffffff81627878 ffff8802242e7cb8
>> > [ 31.664859] ffff8802242e7ca8 ffffffff8104a28d ffff880210610ea8 ffff880224579598
>> > [ 31.664861] ffff8802106140e8 ffff880224578000 0000000000000000 ffff8802242e7d08
>> > [ 31.664863] Call Trace:
>> > [ 31.664865] [<ffffffff81627878>] dump_stack+0x4d/0x66
>> > [ 31.664867] [<ffffffff8104a28d>] warn_slowpath_common+0x7d/0xa0
>> > [ 31.664869] [<ffffffff8104a2fc>] warn_slowpath_fmt+0x4c/0x50
>> > [ 31.664871] [<ffffffff812fdd8c>] __list_add+0xac/0xc0
>> > [ 31.664873] [<ffffffff81055d33>] __internal_add_timer+0x113/0x130
>> > [ 31.664875] [<ffffffff81055f47>] internal_add_timer+0x17/0x40
>> > [ 31.664876] [<ffffffff810587b2>] mod_timer+0x102/0x230
>> > [ 31.664878] [<ffffffff810588f8>] add_timer+0x18/0x20
>> > [ 31.664880] [<ffffffff81572204>] flow_cache_init+0x224/0x2b0
>> > [ 31.664882] [<ffffffff815f7247>] xfrm_net_init+0x227/0x360
>> > [ 31.664884] [<ffffffff815f7171>] ? xfrm_net_init+0x151/0x360
>> > [ 31.664886] [<ffffffff81553131>] ops_init+0x41/0x150
>> > [ 31.664888] [<ffffffff815532b3>] setup_net+0x73/0x110
>> > [ 31.664890] [<ffffffff815537f2>] copy_net_ns+0x72/0x100
>> > [ 31.664892] [<ffffffff81072619>] create_new_namespaces+0xf9/0x190
>> > [ 31.664894] [<ffffffff81072891>] unshare_nsproxy_namespaces+0x61/0xa0
>> > [ 31.664895] [<ffffffff81049949>] SyS_unshare+0x159/0x270
>> > [ 31.664897] [<ffffffff81638092>] system_call_fastpath+0x16/0x1b
>> >
> I was unable to reproduce this here, but it looks like the flowcache
> namespace changes are still not complete. We leak an active timer
> and all the allocated resources when we exit a namespace.
My bad! and embarrassing。。。
Thanks for the fix for my errors.
>
> Could you please try the patch below?
--
浮沉随浪只记今朝笑
--fan
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH net-next] flowcache: Fix resource leaks on namespace exit.
2014-03-12 8:43 ` [PATCH net-next] flowcache: Fix resource leaks on namespace exit Steffen Klassert
@ 2014-03-12 11:43 ` Eric Dumazet
2014-03-12 19:31 ` David Miller
1 sibling, 0 replies; 21+ messages in thread
From: Eric Dumazet @ 2014-03-12 11:43 UTC (permalink / raw)
To: Steffen Klassert; +Cc: Jakub Kiciński, David Miller, netdev, Fan Du
On Wed, 2014-03-12 at 09:43 +0100, Steffen Klassert wrote:
> We leak an active timer, the hotcpu notifier and all allocated
> resources when we exit a namespace. Fix this by introducing a
> flow_cache_fini() function where we release the resources before
> we exit.
>
> Fixes: ca925cf1534e ("flowcache: Make flow cache name space aware")
> Reported-by: Jakub Kicinski <moorray3@wp.pl>
> Tested-by: Jakub Kicinski <moorray3@wp.pl>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: Fan Du <fan.du@windriver.com>
> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
> ---
Acked-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH net-next] flowcache: Fix resource leaks on namespace exit.
2014-03-12 8:43 ` [PATCH net-next] flowcache: Fix resource leaks on namespace exit Steffen Klassert
2014-03-12 11:43 ` Eric Dumazet
@ 2014-03-12 19:31 ` David Miller
1 sibling, 0 replies; 21+ messages in thread
From: David Miller @ 2014-03-12 19:31 UTC (permalink / raw)
To: steffen.klassert; +Cc: moorray3, eric.dumazet, netdev, fan.du
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Wed, 12 Mar 2014 09:43:17 +0100
> We leak an active timer, the hotcpu notifier and all allocated
> resources when we exit a namespace. Fix this by introducing a
> flow_cache_fini() function where we release the resources before
> we exit.
>
> Fixes: ca925cf1534e ("flowcache: Make flow cache name space aware")
> Reported-by: Jakub Kicinski <moorray3@wp.pl>
> Tested-by: Jakub Kicinski <moorray3@wp.pl>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: Fan Du <fan.du@windriver.com>
> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Applied, thanks everyone.
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2014-03-12 19:31 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-03-10 0:44 net-next: NULL pointer dereference on adding a net namespace and a system freeze Jakub Kicinski
2014-03-10 4:02 ` Eric Dumazet
2014-03-10 4:09 ` Eric Dumazet
2014-03-10 6:51 ` Fan Du
2014-03-10 13:44 ` Eric Dumazet
2014-03-10 14:09 ` [PATCH net-next] flowcache: restore a single flow_cache kmem_cache Eric Dumazet
2014-03-11 1:45 ` David Miller
2014-03-10 12:19 ` net-next: NULL pointer dereference on adding a net namespace and a system freeze Jakub Kiciński
2014-03-10 14:04 ` Eric Dumazet
2014-03-11 0:46 ` Jakub Kiciński
2014-03-11 5:30 ` Steffen Klassert
2014-03-11 12:00 ` Steffen Klassert
2014-03-11 12:40 ` Eric Dumazet
2014-03-11 13:20 ` Steffen Klassert
2014-03-11 14:30 ` Jakub Kiciński
2014-03-12 8:38 ` Steffen Klassert
2014-03-12 8:43 ` [PATCH net-next] flowcache: Fix resource leaks on namespace exit Steffen Klassert
2014-03-12 11:43 ` Eric Dumazet
2014-03-12 19:31 ` David Miller
2014-03-11 12:42 ` net-next: NULL pointer dereference on adding a net namespace and a system freeze Jakub Kiciński
2014-03-12 10:02 ` Fan Du
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.