linux-kernel - Re: WARNING: at lib/debugobjects.c:262 debug_print

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <4F1EC7C9.2020001@panasas.com>
Date:	Tue, 24 Jan 2012 17:01:29 +0200
From:	Boaz Harrosh <bharrosh@...asas.com>
To:	Jeff Layton <jlayton@...hat.com>
CC:	Stanislaw Gruszka <sgruszka@...hat.com>,
	Stephen Boyd <sboyd@...eaurora.org>,
	<linux-kernel@...r.kernel.org>, <bfields@...hat.com>,
	<linux-nfs@...r.kernel.org>, Thomas Gleixner <tglx@...utronix.de>,
	Tejun Heo <tj@...nel.org>
Subject: Re: WARNING: at lib/debugobjects.c:262 debug_print_object+0x8c/0xb0()

On 01/24/2012 02:36 PM, Jeff Layton wrote:
> 
> No, I don't think the state would be undefined after
> cancel_delayed_work_sync. In principle you could requeue that work
> again if you like without needing to reinitialize it.
> 
> I think this is a problem in the debugobjects code. It doesn't have
> any way to know that when the object is recycled out of the slab that
> the work is already initialized.
> 

The only difference between your above example of requeue after
cancel_delayed_work_sync, and this here is the visit back to the
slab. Does the slab (Maybe in debug mode) stumps over some of the
record memory?

If the memory is constant what is then the difference between the two
cases?

> Certainly it's simple enough to reinitialize the work every time we
> allocate an inode here, but I don't think this is really a rpc_pipefs
> bug per-se. 

That depends on the API intention. If an init is intended after
SLAB free then yes if not then not. We should ask for the intention
of this API.

> I can send a patch that works around this problem, but
> if there are plans to fix this in the debugobjects code, I won't
> bother...
> 

You mean other fix then calling INIT_DELAYED_WORK? is that so
bad that we need more code to avoid it?

Thanks
Boaz
--
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/