linux-kernel - Re: netfilter: active obj WARN when cleaning up

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <52B300C7.7090808@acm.org>
Date:	Thu, 19 Dec 2013 15:20:55 +0100
From:	Bart Van Assche <bvanassche@....org>
To:	Sasha Levin <sasha.levin@...cle.com>,
	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/19/13 13:12, Bart Van Assche wrote:
> On 12/17/13 20:53, Sasha Levin wrote:
>> 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: delayed_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 ]---
> 
> Can anyone tell me whether the patch below makes sense ?
> 
> [ ... ]

(replying to my own e-mail)

Please ignore the patch in the previous e-mail - it did not make sense.

Regarding the warning above: the "delayed_work_timer_fn+0x0/0x20" hint
probably indicates an attempt to free a delayed_work structure that is
embedded in struct rtc_device and that is still scheduled. It's
unfortunate that debug_check_no_obj_freed() does not print the address
of the offending object and the argument passed to kfree(). That
information would allow to compute the offset of the embedded
delayed_work structure make it easier to figure out what's going on.

Bart.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/