* A regression introduced by 802.1ad support patches
@ 2013-04-21 7:43 Cong Wang
2013-04-21 9:34 ` Patrick McHardy
0 siblings, 1 reply; 4+ messages in thread
From: Cong Wang @ 2013-04-21 7:43 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netdev, David S. Miller
Hi, Patrick,
Your recent 802.1ad patches causes the following bug. After resetting
HEAD to commit c296289 (Merge branch 'intel'), this bug is not
reproducible any more.
It is pretty easy to reproduce in my KVM guest, just boot the guest and
then shut it down, the following traces will be shown. Although it is
not 100% reproducible, it appears more than 80% times at least.
I am glad to provide any other information if you need, and of course
can test any fix if you want.
[ 86.812073] kmemleak: Found object by alias at 0xffff88006ecc76f0
[ 86.816019] Pid: 739, comm: kworker/u:1 Not tainted 3.9.0-rc5+ #842
[ 86.816019] Call Trace:
[ 86.816019] <IRQ> [<ffffffff81151c58>] find_and_get_object
+0x8c/0xdf
[ 86.816019] [<ffffffff8190e90d>] ? vlan_info_rcu_free+0x33/0x49
[ 86.816019] [<ffffffff81151cbe>] delete_object_full+0x13/0x2f
[ 86.816019] [<ffffffff8194bbb6>] kmemleak_free+0x26/0x45
[ 86.816019] [<ffffffff8113e8c7>] slab_free_hook+0x1e/0x7b
[ 86.816019] [<ffffffff81141c05>] kfree+0xce/0x14b
[ 86.816019] [<ffffffff8190e90d>] vlan_info_rcu_free+0x33/0x49
[ 86.816019] [<ffffffff810d0b0b>] rcu_do_batch+0x261/0x4e7
[ 86.816019] [<ffffffff810a308f>] ? mark_held_locks+0x6d/0x95
[ 86.816019] [<ffffffff8190e8da>] ? __vlan_vid_del+0xa6/0xa6
[ 86.816019] [<ffffffff810d0e99>] __rcu_process_callbacks+0x108/0x133
[ 86.816019] [<ffffffff810d0f09>] rcu_process_callbacks+0x45/0x72
[ 86.816019] [<ffffffff81058163>] __do_softirq+0x133/0x2a3
[ 86.816019] [<ffffffff8105840c>] irq_exit+0x5d/0xa4
[ 86.816019] [<ffffffff81983751>] smp_apic_timer_interrupt+0x7c/0x8a
[ 86.816019] [<ffffffff81982832>] apic_timer_interrupt+0x72/0x80
[ 86.816019] <EOI> [<ffffffff8102f3e0>] ? __flush_tlb_all+0x15/0x22
[ 86.816019] [<ffffffff8145b427>] ? clear_page_c+0x7/0x10
[ 86.816019] [<ffffffff81105203>] ? prep_new_page+0x133/0x17f
[ 86.816019] [<ffffffff8110567e>] ? get_page_from_freelist
+0x42f/0x523
[ 86.816019] [<ffffffff811056a6>] get_page_from_freelist+0x457/0x523
[ 86.816019] [<ffffffff810a37b9>] ? lock_is_held+0x56/0x60
[ 86.816019] [<ffffffff811058d6>] __alloc_pages_nodemask+0x164/0x700
[ 86.816019] [<ffffffff81029e91>] ? kvm_clock_read+0x34/0x3b
[ 86.816019] [<ffffffff810852e9>] ? local_clock+0x14/0x4f
[ 86.816019] [<ffffffff81029e91>] ? kvm_clock_read+0x34/0x3b
[ 86.816019] [<ffffffff810852e9>] ? local_clock+0x14/0x4f
[ 86.816019] [<ffffffff810e595b>] ? time_hardirqs_off+0x15/0x2a
[ 86.816019] [<ffffffff8108530b>] ? local_clock+0x36/0x4f
[ 86.816019] [<ffffffff8108530b>] ? local_clock+0x36/0x4f
[ 86.816019] [<ffffffff81139f94>] alloc_pages_current+0xfa/0x11b
[ 86.816019] [<ffffffff811029b6>] __get_free_pages+0x16/0x44
[ 86.816019] [<ffffffff811029fa>] get_zeroed_page+0x16/0x18
[ 86.816019] [<ffffffff81121bd8>] __pud_alloc+0x20/0xa4
[ 86.816019] [<ffffffff81121c74>] pud_alloc+0x18/0x30
[ 86.816019] [<ffffffff81121df2>] handle_mm_fault+0x92/0x264
[ 86.816019] [<ffffffff81122375>] __get_user_pages+0x31d/0x4bb
[ 86.816019] [<ffffffff81154759>] ? do_sync_read+0x6d/0xaa
[ 86.816019] [<ffffffff811225ba>] get_user_pages+0x52/0x54
[ 86.816019] [<ffffffff81159614>] get_arg_page+0x5a/0xc4
[ 86.816019] [<ffffffff81084631>] ? __might_sleep+0xbe/0x19b
[ 86.816019] [<ffffffff811597b1>] copy_strings+0x133/0x210
[ 86.816019] [<ffffffff8115a443>] copy_strings_kernel+0x53/0x61
[ 86.816019] [<ffffffff8115b145>] do_execve_common+0x1c1/0x338
[ 86.816019] [<ffffffff8115b2fc>] do_execve+0x40/0x42
[ 86.816019] [<ffffffff8106844d>] ____call_usermodehelper+0x100/0x11a
[ 86.816019] [<ffffffff81068467>] ? ____call_usermodehelper
+0x11a/0x11a
[ 86.816019] [<ffffffff81068485>] call_helper+0x1e/0x20
[ 86.816019] [<ffffffff81981aec>] ret_from_fork+0x7c/0xb0
[ 86.816019] [<ffffffff81068467>] ? ____call_usermodehelper
+0x11a/0x11a
[ 86.816019] kmemleak: Object 0xffff88006ecc76d0 (size 256):
[ 86.816019] kmemleak: comm "NetworkManager", pid 342, jiffies
4294896763
[ 86.816019] kmemleak: min_count = 1
[ 86.816019] kmemleak: count = 1
[ 86.816019] kmemleak: flags = 0x1
[ 86.816019] kmemleak: checksum = 0
[ 86.816019] kmemleak: backtrace:
[ 86.816019] [<ffffffff8194bae0>] kmemleak_alloc+0x26/0x43
[ 86.816019] [<ffffffff8113e771>] slab_post_alloc_hook+0x28/0x2a
[ 86.816019] [<ffffffff8114183d>] __kmalloc+0x114/0x145
[ 86.816019] [<ffffffff8190e9ea>] kzalloc.constprop.4+0xe/0x10
[ 86.816019] [<ffffffff8190f008>] vlan_vid_add+0x98/0x146
[ 86.816019] [<ffffffff8190f8d1>] vlan_device_event+0xbb/0x3c4
[ 86.816019] [<ffffffff8107896f>] notifier_call_chain+0x96/0xcd
[ 86.816019] [<ffffffff81078d35>] raw_notifier_call_chain
+0x14/0x16
[ 86.816019] [<ffffffff8176e68e>] call_netdevice_notifiers
+0x4a/0x4f
[ 86.816019] [<ffffffff81771aed>] __dev_notify_flags+0x37/0x5b
[ 86.816019] [<ffffffff81771b59>] dev_change_flags+0x48/0x53
[ 86.816019] [<ffffffff8177e743>] do_setlink+0x29e/0x5d6
[ 86.816019] [<ffffffff8177f0d1>] rtnl_newlink+0x257/0x436
[ 86.816019] [<ffffffff8177d80f>] rtnetlink_rcv_msg+0x19c/0x1ab
[ 86.816019] [<ffffffff817c5a1f>] netlink_rcv_skb+0x42/0x8d
[ 86.816019] [<ffffffff8177d655>] rtnetlink_rcv+0x26/0x2d
<..........More traces are snipped here...........>
Thanks!
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: A regression introduced by 802.1ad support patches
2013-04-21 7:43 A regression introduced by 802.1ad support patches Cong Wang
@ 2013-04-21 9:34 ` Patrick McHardy
2013-04-21 9:49 ` Cong Wang
0 siblings, 1 reply; 4+ messages in thread
From: Patrick McHardy @ 2013-04-21 9:34 UTC (permalink / raw)
To: Cong Wang; +Cc: netdev, David S. Miller
[-- Attachment #1: Type: text/plain, Size: 1320 bytes --]
On Sun, Apr 21, 2013 at 03:43:04PM +0800, Cong Wang wrote:
> Hi, Patrick,
>
> Your recent 802.1ad patches causes the following bug. After resetting
> HEAD to commit c296289 (Merge branch 'intel'), this bug is not
> reproducible any more.
>
> It is pretty easy to reproduce in my KVM guest, just boot the guest and
> then shut it down, the following traces will be shown. Although it is
> not 100% reproducible, it appears more than 80% times at least.
>
> I am glad to provide any other information if you need, and of course
> can test any fix if you want.
>
> [ 86.812073] kmemleak: Found object by alias at 0xffff88006ecc76f0
> [ 86.816019] Pid: 739, comm: kworker/u:1 Not tainted 3.9.0-rc5+ #842
> [ 86.816019] Call Trace:
> [ 86.816019] <IRQ> [<ffffffff81151c58>] find_and_get_object
> +0x8c/0xdf
> [ 86.816019] [<ffffffff8190e90d>] ? vlan_info_rcu_free+0x33/0x49
> [ 86.816019] [<ffffffff81151cbe>] delete_object_full+0x13/0x2f
> [ 86.816019] [<ffffffff8194bbb6>] kmemleak_free+0x26/0x45
> [ 86.816019] [<ffffffff8113e8c7>] slab_free_hook+0x1e/0x7b
> [ 86.816019] [<ffffffff81141c05>] kfree+0xce/0x14b
> [ 86.816019] [<ffffffff8190e90d>] vlan_info_rcu_free+0x33/0x49
> [ 86.816019] [<ffffffff810d0b0b>] rcu_do_batch+0x261/0x4e7
Thanks. I think the attached patch should fix it.
[-- Attachment #2: vlan-leak.diff --]
[-- Type: text/plain, Size: 1783 bytes --]
commit 77734833d78bcf0a3f58cde8b5b2424e8fc8b7e6
Author: Patrick McHardy <kaber@trash.net>
Date: Sun Apr 21 11:34:12 2013 +0200
net: vlan: fix memory leak in vlan_info_rcu_free()
The following leak is reported by kmemleak:
[ 86.812073] kmemleak: Found object by alias at 0xffff88006ecc76f0
[ 86.816019] Pid: 739, comm: kworker/u:1 Not tainted 3.9.0-rc5+ #842
[ 86.816019] Call Trace:
[ 86.816019] <IRQ> [<ffffffff81151c58>] find_and_get_object+0x8c/0xdf
[ 86.816019] [<ffffffff8190e90d>] ? vlan_info_rcu_free+0x33/0x49
[ 86.816019] [<ffffffff81151cbe>] delete_object_full+0x13/0x2f
[ 86.816019] [<ffffffff8194bbb6>] kmemleak_free+0x26/0x45
[ 86.816019] [<ffffffff8113e8c7>] slab_free_hook+0x1e/0x7b
[ 86.816019] [<ffffffff81141c05>] kfree+0xce/0x14b
[ 86.816019] [<ffffffff8190e90d>] vlan_info_rcu_free+0x33/0x49
[ 86.816019] [<ffffffff810d0b0b>] rcu_do_batch+0x261/0x4e7
The reason is that in vlan_info_rcu_free() we don't take the VLAN protocol
into account when iterating over the vlan_devices_array.
Reported-by: Cong Wang <amwang@redhat.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
diff --git a/net/8021q/vlan_core.c b/net/8021q/vlan_core.c
index ebfa2fc..8a15eaa 100644
--- a/net/8021q/vlan_core.c
+++ b/net/8021q/vlan_core.c
@@ -157,10 +157,11 @@ EXPORT_SYMBOL(vlan_untag);
static void vlan_group_free(struct vlan_group *grp)
{
- int i;
+ int i, j;
- for (i = 0; i < VLAN_GROUP_ARRAY_SPLIT_PARTS; i++)
- kfree(grp->vlan_devices_arrays[i]);
+ for (i = 0; i < VLAN_PROTO_NUM; i++)
+ for (j = 0; j < VLAN_GROUP_ARRAY_SPLIT_PARTS; j++)
+ kfree(grp->vlan_devices_arrays[i][j]);
}
static void vlan_info_free(struct vlan_info *vlan_info)
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: A regression introduced by 802.1ad support patches
2013-04-21 9:34 ` Patrick McHardy
@ 2013-04-21 9:49 ` Cong Wang
2013-04-21 19:56 ` David Miller
0 siblings, 1 reply; 4+ messages in thread
From: Cong Wang @ 2013-04-21 9:49 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netdev, David S. Miller
On Sun, 2013-04-21 at 11:34 +0200, Patrick McHardy wrote:
> commit 77734833d78bcf0a3f58cde8b5b2424e8fc8b7e6
> Author: Patrick McHardy <kaber@trash.net>
> Date: Sun Apr 21 11:34:12 2013 +0200
>
> net: vlan: fix memory leak in vlan_info_rcu_free()
>
> The following leak is reported by kmemleak:
>
> [ 86.812073] kmemleak: Found object by alias at
> 0xffff88006ecc76f0
> [ 86.816019] Pid: 739, comm: kworker/u:1 Not tainted 3.9.0-rc5+
> #842
> [ 86.816019] Call Trace:
> [ 86.816019] <IRQ> [<ffffffff81151c58>] find_and_get_object
> +0x8c/0xdf
> [ 86.816019] [<ffffffff8190e90d>] ? vlan_info_rcu_free
> +0x33/0x49
> [ 86.816019] [<ffffffff81151cbe>] delete_object_full+0x13/0x2f
> [ 86.816019] [<ffffffff8194bbb6>] kmemleak_free+0x26/0x45
> [ 86.816019] [<ffffffff8113e8c7>] slab_free_hook+0x1e/0x7b
> [ 86.816019] [<ffffffff81141c05>] kfree+0xce/0x14b
> [ 86.816019] [<ffffffff8190e90d>] vlan_info_rcu_free+0x33/0x49
> [ 86.816019] [<ffffffff810d0b0b>] rcu_do_batch+0x261/0x4e7
>
> The reason is that in vlan_info_rcu_free() we don't take the VLAN
> protocol
> into account when iterating over the vlan_devices_array.
>
> Reported-by: Cong Wang <amwang@redhat.com>
> Signed-off-by: Patrick McHardy <kaber@trash.net>
Yes, indeed.
Tested-by: Cong Wang <amwang@redhat.com>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: A regression introduced by 802.1ad support patches
2013-04-21 9:49 ` Cong Wang
@ 2013-04-21 19:56 ` David Miller
0 siblings, 0 replies; 4+ messages in thread
From: David Miller @ 2013-04-21 19:56 UTC (permalink / raw)
To: amwang; +Cc: kaber, netdev
From: Cong Wang <amwang@redhat.com>
Date: Sun, 21 Apr 2013 17:49:17 +0800
> On Sun, 2013-04-21 at 11:34 +0200, Patrick McHardy wrote:
>> commit 77734833d78bcf0a3f58cde8b5b2424e8fc8b7e6
>> Author: Patrick McHardy <kaber@trash.net>
>> Date: Sun Apr 21 11:34:12 2013 +0200
>>
>> net: vlan: fix memory leak in vlan_info_rcu_free()
>>
>> The following leak is reported by kmemleak:
>>
>> [ 86.812073] kmemleak: Found object by alias at
>> 0xffff88006ecc76f0
>> [ 86.816019] Pid: 739, comm: kworker/u:1 Not tainted 3.9.0-rc5+
>> #842
>> [ 86.816019] Call Trace:
>> [ 86.816019] <IRQ> [<ffffffff81151c58>] find_and_get_object
>> +0x8c/0xdf
>> [ 86.816019] [<ffffffff8190e90d>] ? vlan_info_rcu_free
>> +0x33/0x49
>> [ 86.816019] [<ffffffff81151cbe>] delete_object_full+0x13/0x2f
>> [ 86.816019] [<ffffffff8194bbb6>] kmemleak_free+0x26/0x45
>> [ 86.816019] [<ffffffff8113e8c7>] slab_free_hook+0x1e/0x7b
>> [ 86.816019] [<ffffffff81141c05>] kfree+0xce/0x14b
>> [ 86.816019] [<ffffffff8190e90d>] vlan_info_rcu_free+0x33/0x49
>> [ 86.816019] [<ffffffff810d0b0b>] rcu_do_batch+0x261/0x4e7
>>
>> The reason is that in vlan_info_rcu_free() we don't take the VLAN
>> protocol
>> into account when iterating over the vlan_devices_array.
>>
>> Reported-by: Cong Wang <amwang@redhat.com>
>> Signed-off-by: Patrick McHardy <kaber@trash.net>
>
> Yes, indeed.
>
> Tested-by: Cong Wang <amwang@redhat.com>
Applied.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2013-04-21 19:56 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-04-21 7:43 A regression introduced by 802.1ad support patches Cong Wang
2013-04-21 9:34 ` Patrick McHardy
2013-04-21 9:49 ` Cong Wang
2013-04-21 19:56 ` David Miller
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox