From: Sasha Levin <sasha.levin@oracle.com>
To: Christoph Lameter <cl@linux.com>, Greg KH <greg@kroah.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Russell King - ARM Linux <linux@arm.linux.org.uk>,
Pablo Neira Ayuso <pablo@netfilter.org>,
Patrick McHardy <kaber@trash.net>,
kadlec@blackhole.kfki.hu, "David S. Miller" <davem@davemloft.net>,
netfilter-devel@vger.kernel.org, coreteam@netfilter.org,
netdev@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>
Subject: Re: netfilter: active obj WARN when cleaning up
Date: Tue, 17 Dec 2013 14:53:26 -0500 [thread overview]
Message-ID: <52B0ABB6.8090205@oracle.com> (raw)
In-Reply-To: <00000142b90da700-19f6b465-ff15-4b2b-9bcd-b91d71958b7f-000000@email.amazonses.com>
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@linux.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, 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>
next prev parent reply other threads:[~2013-12-17 19:53 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-07 13:10 netfilter: active obj WARN when cleaning up Sasha Levin
2013-11-26 19:11 ` Sasha Levin
2013-11-26 23:07 ` Pablo Neira Ayuso
2013-11-26 23:13 ` Sasha Levin
2013-11-27 10:45 ` Thomas Gleixner
2013-11-27 11:39 ` Russell King - ARM Linux
2013-11-27 13:29 ` Thomas Gleixner
2013-11-27 13:32 ` Russell King - ARM Linux
2013-11-27 13:40 ` Russell King - ARM Linux
2013-11-27 13:44 ` Thomas Gleixner
2013-11-27 23:34 ` Greg KH
2013-12-02 16:33 ` Christoph Lameter
2013-12-02 16:40 ` Greg KH
2013-12-02 17:18 ` Christoph Lameter
2013-12-02 17:26 ` Greg KH
2013-12-02 19:00 ` Christoph Lameter
2013-12-02 19:08 ` Greg KH
2013-12-02 19:41 ` Christoph Lameter
2013-12-02 21:22 ` Greg KH
2013-12-02 21:55 ` Christoph Lameter
2013-12-02 22:22 ` Greg KH
2013-12-03 15:22 ` Christoph Lameter
2013-12-17 19:53 ` Sasha Levin [this message]
2013-12-17 20:37 ` Christoph Lameter
2013-12-17 22:09 ` Sasha Levin
2013-12-17 22:01 ` Thomas Gleixner
2013-12-19 12:12 ` Bart Van Assche
2013-12-19 14:20 ` Bart Van Assche
2013-11-27 13:41 ` Thomas Gleixner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52B0ABB6.8090205@oracle.com \
--to=sasha.levin@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=coreteam@netfilter.org \
--cc=davem@davemloft.net \
--cc=greg@kroah.com \
--cc=kaber@trash.net \
--cc=kadlec@blackhole.kfki.hu \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux@arm.linux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).