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]

Message-ID: <Pine.LNX.4.44L0.0711301702200.2747-100000@iolanthe.rowland.org>
Date:	Fri, 30 Nov 2007 17:10:33 -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:

> Ok, how about this:
> 	void kobject_init(struct kobject *kobj, struct ktype *ktype);
> 
> and then:
> 	int kobject_add(struct kobject *kobj, struct kobject *parent, const char *fmt, ...);
> 
> After we call kobject_init() we HAVE to call kobject_put() to clean up
> properly.  So, if kobject_add() fails, we still need to clean up with
> kobject_put();

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().

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.

The same sort of rule should apply to other kernel objects, like struct 
device.  After intialization you have to do a final _put, before that 
you just do a kfree().  (And initialization cannot fail.)

> That means we _can_ create a:
> 	int kobject_init_and_add(struct kobject *kobj, struct ktype *ktype, struct kobject *parent, const char *fmt, ...);
> 
> and if that fails, then again, you have to call kobject_put() to clean
> things up, right?

Right.  Because you know that the failure must have occurred in the 
_add portion.

> Does this look sane?

Yes, I think that will all work correctly.

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/