linux-kernel - Re: [RFC] kobject: add kobject_init_ng and kobject_init_and

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]

Date:	Fri, 30 Nov 2007 18:22:37 -0500 (EST)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Greg KH <greg@...ah.com>
cc:	Cornelia Huck <cornelia.huck@...ibm.com>,
	Kay Sievers <kay.sievers@...y.org>,
	Kernel development list <linux-kernel@...r.kernel.org>,
	Jonathan Corbet <corbet@....net>,
	Randy Dunlap <randy.dunlap@...cle.com>
Subject: Re: [RFC] kobject: add kobject_init_ng and kobject_init_and_add
 functions

On Fri, 30 Nov 2007, Greg KH wrote:

> > However if kobject_add() is never called, or if it is called and it 
> > fails, then it's okay to use kfree().  It's not clear whether this 
> > distinction will matter in practice.  It's probably best to document 
> > this using your stronger description.
> 
> No, if kobject_add() fails, kobject_put() still must be called in order
> to free up the name pointer, unless you are somehow guessing that the
> "kobject_set_name()" portion of kobject_add() somehow failed.

Actually I imagined that if kobject_add() failed it would back out all 
the changes it made -- which means it would deallocate the name 
string.  But requiring people to call kobject_put() will do this just 
as well.

>  And you
> can't know that, so you have to call kobject_put() in order to be safe
> and clean up everything.
> 
> Now why did we not do the final kobject_put() in kobject_del() as well?
> Doing two calls, always in order, seems a bit strange, anyone know why
> it's this way?

To be symmetrical with kobject_init() and kobject_add().  Besides, 
isn't there kobject_unregister()?  Presumably it will go away along 
with kobject_register(), though.

> > You could put that a little less strongly.  After kobject_init() you
> > SHOULD call kobject_put() to clean up properly, and after kobject_add()
> > you MUST call kobject_del() and kobject_put().
>
> No, in looking at the code, you only need to call kobject_del() to clean
> everything up properly, if kobject_add() succeeds.  No need to call
> kobject_put() yet again.

Sorry, yes, that's what I meant.  After a successful call to 
kobject_add() you must call kobject_del() to undo the _add, and then
kobject_put() for the final cleanup.

Alan Stern

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