[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <52B0ABB6.8090205@oracle.com>
Date: Tue, 17 Dec 2013 14:53:26 -0500
From: Sasha Levin <sasha.levin@...cle.com>
To: Christoph Lameter <cl@...ux.com>, Greg KH <greg@...ah.com>
CC: Thomas Gleixner <tglx@...utronix.de>,
Russell King - ARM Linux <linux@....linux.org.uk>,
Pablo Neira Ayuso <pablo@...filter.org>,
Patrick McHardy <kaber@...sh.net>, kadlec@...ckhole.kfki.hu,
"David S. Miller" <davem@...emloft.net>,
netfilter-devel@...r.kernel.org, coreteam@...filter.org,
netdev@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
linux-mm@...ck.org, Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: netfilter: active obj WARN when cleaning up
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@...ux.com>
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 netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists