Re: netfilter: active obj WARN when cleaning up
From: Sasha Levin
Date: Tue Dec 17 2013 - 14:54:42 EST
On 12/03/2013 10:22 AM, Christoph Lameter wrote:
On Mon, 2 Dec 2013, Greg KH wrote:
Your release function had 2 tabs for the lines, not one.
Ah ok. Fixed.
Index: linux/include/linux/slub_def.h
===================================================================
--- linux.orig/include/linux/slub_def.h 2013-12-02 13:31:07.395905824 -0600
+++ linux/include/linux/slub_def.h 2013-12-02 13:31:07.385906101 -0600
@@ -98,4 +98,8 @@ struct kmem_cache {
struct kmem_cache_node *node[MAX_NUMNODES];
};
+#ifdef CONFIG_SYSFS
+#define SLAB_SUPPORTS_SYSFS
Why even define this? Why not just use CONFIG_SYSFS?
Because not all slab allocators currently support SYSFS and there is the
need to have different code now in slab_common.c depending on the
configuration of the allocator.
But you are defining something that you only ever check once, why not
just use CONFIG_SYSFS instead as it makes more sense, not the other way
around.
We cannot use CONFIG_SYSFS otherwise it would break SLAB since some of
the code modified is shared between allocators. SLAB currently does not
support sysfs. When we add that then we can get rid of the #define.
Subject: slub: use sysfs'es release mechanism for kmem_cache
Sysfs has a release mechanism. Use that to release the kmem_cache structure
if CONFIG_SYSFS is enabled.
Signed-off-by: Christoph Lameter <cl@xxxxxxxxx>
I'm still seeing warnings with this patch applied:
[ 24.900482] WARNING: CPU: 12 PID: 3654 at lib/debugobjects.c:260 debug_print_object+
0x8d/0xb0()
[ 24.900482] ODEBUG: free active (active state 0) object type: timer_list hint: delay
ed_work_timer_fn+0x0/0x20
[ 24.900482] Modules linked in:
[ 24.900482] CPU: 12 PID: 3654 Comm: kworker/12:1 Tainted: G W 3.13.0-rc4-n
ext-20131217-sasha-00013-ga878504-dirty #4149
[ 24.900482] Workqueue: events kobject_delayed_cleanup
[ 24.900482] 0000000000000104 ffff8804f429bae8 ffffffff8439501c ffffffff8555a92c
[ 24.900482] ffff8804f429bb38 ffff8804f429bb28 ffffffff8112f8ac ffff8804f429bb58
[ 24.900482] ffffffff856a9413 ffff880826333530 ffffffff85c68c40 ffffffff8801bb58
[ 24.900482] Call Trace:
[ 24.900482] [<ffffffff8439501c>] dump_stack+0x52/0x7f
[ 24.900482] [<ffffffff8112f8ac>] warn_slowpath_common+0x8c/0xc0
[ 24.900482] [<ffffffff8112f996>] warn_slowpath_fmt+0x46/0x50
[ 24.900482] [<ffffffff81adb50d>] debug_print_object+0x8d/0xb0
[ 24.900482] [<ffffffff81153090>] ? __queue_work+0x3f0/0x3f0
[ 24.900482] [<ffffffff81adbd15>] __debug_check_no_obj_freed+0xa5/0x220
[ 24.900482] [<ffffffff832b1acb>] ? rtc_device_release+0x2b/0x40
[ 24.900482] [<ffffffff832b1acb>] ? rtc_device_release+0x2b/0x40
[ 24.900482] [<ffffffff81adbea5>] debug_check_no_obj_freed+0x15/0x20
[ 24.900482] [<ffffffff812ad54f>] kfree+0x21f/0x2e0
[ 24.900482] [<ffffffff832b1acb>] rtc_device_release+0x2b/0x40
[ 24.900482] [<ffffffff8207efd5>] device_release+0x65/0xc0
[ 24.900482] [<ffffffff81ab05e5>] kobject_cleanup+0x145/0x190
[ 24.900482] [<ffffffff81ab063d>] kobject_delayed_cleanup+0xd/0x10
[ 24.900482] [<ffffffff81153a60>] process_one_work+0x320/0x530
[ 24.900482] [<ffffffff81153940>] ? process_one_work+0x200/0x530
[ 24.900482] [<ffffffff81155fe5>] worker_thread+0x215/0x350
[ 24.900482] [<ffffffff81155dd0>] ? manage_workers+0x180/0x180
[ 24.900482] [<ffffffff8115c9c5>] kthread+0x105/0x110
[ 24.900482] [<ffffffff8115c8c0>] ? set_kthreadd_affinity+0x30/0x30
[ 24.900482] [<ffffffff843a5e7c>] ret_from_fork+0x7c/0xb0
[ 24.900482] [<ffffffff8115c8c0>] ? set_kthreadd_affinity+0x30/0x30
[ 24.900482] ---[ end trace 45529ebf79b2573e ]---
Thanks,
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/