Re: [PATCH] kobject: make sure kobj->ktype is set before kobject_init

[Alan Stern <stern@rowland.harvard.edu>]

On Thu, 29 Nov 2007, Kay Sievers wrote:

> > My conclusion is different.  We should make kobject_init() not consume
> > any resources at all; just initialize various fields.  That way it
> > would be okay to call either kfree() or kobject_put() on an initialized
> > kobject.  And then when something like device_register() fails, the
> > caller would know the proper thing to do would be to call the put()  
> > routine, always.
> > 
> > Of course, once the name has been assigned, only kobject_put() should
> > be used.
> 
> Now we just move the exactly the same problem from _init() to
> _set_name(). To free the name of an unregistered we would need to call
> _put() which free()'s the whole object again. :) 

I don't see that as a problem and it's not clear why you do.

It doesn't matter whether a kobject has been registered or not; once
it has been initialized you _should_ call kobject_put().  (Although
it's okay to call kfree() if the name hasn't been set yet.)

The same is true of larger objects.  Once you have called
device_initialize(), you _should_ call device_put() (although it's okay
to call kfree()).  Provided init routines don't consume resources, this
will work.

The only remaining problem is that somebody might set the name first
and then decide to abandon the object before calling kobject_init().  
However this probably never happens anywhere.

> > There's another good reason for not assigning the name in
> > kobject_init(): Code that uses kobjects (like the driver core) doesn't
> > set the name until later.
> 
> That can be done at any stage, I guess. We will rip out the name in the
> struct device anyway.

Are you also going to change all the places in the kernel where the
device name (.bus_id) isn't set until after device_initialize() has
been called?

Alan Stern

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