Re: netfilter: active obj WARN when cleaning up
From: Sasha Levin <hidden>
Date: 2013-12-17 19:54:39
Also in:
linux-mm, lkml, netfilter-devel
On 12/03/2013 10:22 AM, Christoph Lameter wrote:
On Mon, 2 Dec 2013, Greg KH wrote:quoted
Your release function had 2 tabs for the lines, not one.Ah ok. Fixed.quoted
quoted
quoted
quoted
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_SYSFSWhy 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 <redacted>
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, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>