All of lore.kernel.org
 help / color / mirror / Atom feed
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>

WARNING: multiple messages have this Message-ID (diff)
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


  reply	other threads:[~2013-12-17 19:53 UTC|newest]

Thread overview: 55+ 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 10:45       ` Thomas Gleixner
2013-11-27 11:39       ` Russell King - ARM Linux
2013-11-27 11:39         ` Russell King - ARM Linux
2013-11-27 13:29         ` Thomas Gleixner
2013-11-27 13:29           ` Thomas Gleixner
2013-11-27 13:32           ` Russell King - ARM Linux
2013-11-27 13:32             ` Russell King - ARM Linux
2013-11-27 13:40             ` Russell King - ARM Linux
2013-11-27 13:40               ` Russell King - ARM Linux
2013-11-27 13:44               ` Thomas Gleixner
2013-11-27 13:44                 ` Thomas Gleixner
2013-11-27 23:34                 ` Greg KH
2013-11-27 23:34                   ` Greg KH
2013-12-02 16:33                   ` Christoph Lameter
2013-12-02 16:33                     ` Christoph Lameter
2013-12-02 16:40                     ` Greg KH
2013-12-02 16:40                       ` Greg KH
2013-12-02 17:18                       ` Christoph Lameter
2013-12-02 17:18                         ` Christoph Lameter
2013-12-02 17:26                         ` Greg KH
2013-12-02 17:26                           ` Greg KH
2013-12-02 19:00                           ` Christoph Lameter
2013-12-02 19:00                             ` Christoph Lameter
2013-12-02 19:08                             ` Greg KH
2013-12-02 19:08                               ` Greg KH
2013-12-02 19:41                               ` Christoph Lameter
2013-12-02 19:41                                 ` Christoph Lameter
2013-12-02 21:22                                 ` Greg KH
2013-12-02 21:22                                   ` Greg KH
2013-12-02 21:55                                   ` Christoph Lameter
2013-12-02 21:55                                     ` Christoph Lameter
2013-12-02 22:22                                     ` Greg KH
2013-12-02 22:22                                       ` Greg KH
2013-12-03 15:22                                       ` Christoph Lameter
2013-12-03 15:22                                         ` Christoph Lameter
2013-12-17 19:53                                         ` Sasha Levin [this message]
2013-12-17 19:53                                           ` Sasha Levin
2013-12-17 20:37                                           ` Christoph Lameter
2013-12-17 20:37                                             ` Christoph Lameter
2013-12-17 22:09                                             ` Sasha Levin
2013-12-17 22:09                                               ` Sasha Levin
2013-12-17 22:09                                               ` Sasha Levin
2013-12-17 22:01                                           ` Thomas Gleixner
2013-12-17 22:01                                             ` Thomas Gleixner
2013-12-19 12:12                                           ` Bart Van Assche
2013-12-19 12:12                                             ` Bart Van Assche
2013-12-19 14:20                                             ` Bart Van Assche
2013-12-19 14:20                                               ` Bart Van Assche
2013-11-27 13:41             ` Thomas Gleixner
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.