Messages in this thread Patch in this message | | | From | Jason Noakes <> | Date | Sun, 5 Oct 2014 16:47:42 -0400 | Subject | Re: kobject_init and the zeroed-out-memory requirement |
| |
> Is there any in-kernel code that does not properly zero out the memory > before calling kobject_init()?
I'm not sure. I didn't find any, but I've seen it bite people writing drivers more than once where I work, and the latest oops I just debugged a few days ago prompted me to address the issue and at least get the documentation updated.
>> Many other *_init kernel routines (cdev_init, kref_init, mutex_init, >> spin_lock_init, etc) do not have the same requirement - they work on fully >> uninitialized memory. > > They all do different things, you can't compare apples to oranges :)
Well, they are all named "_init", which to me implies that they initialize the object/memory passed in, which is true in all of the other cases I mentioned, but not for kobject_init. Perhaps it should have been called kobject_setup or something. But I digress...
>> Documentation/kobject.txt does not mention the requirement that the memory be >> zero-initialized before it is passed to kobject_init. > > Add a line of text to the kerneldoc for kobject_init to mention this? > > Or (a) is fine as well, if it makes you feel better, but if you do so, > just say that all memory for kobjects must be created with kzalloc() and > don't mention memset as that will cause people to try to reuse kobjects, > like they have in the past, and bad things will happen then.
Here is a patch updating the documentation (kobject.txt and kobject_init's usage documentation) so that the zeroed-out-memory requirement is explicit.
Signed-off-by: Jason J. Noakes <jjnoakes@gmail.com>
diff --git a/Documentation/kobject.txt b/Documentation/kobject.txt index f87241d..1b38727 100644 --- a/Documentation/kobject.txt +++ b/Documentation/kobject.txt @@ -113,8 +113,14 @@ question. That macro is subsequently invoked with:
Initialization of kobjects
-Code which creates a kobject must, of course, initialize that object. Some -of the internal fields are setup with a (mandatory) call to kobject_init(): +Code which creates a kobject must, of course, initialize that object. + +First, ensure the memory for the kobject is initialized to zero; this is +typically accomplished by obtaining the memory for the kobject (and the +structure it is embedded in) from a call to kzalloc(). + +Then, some of the internal fields must be setup with a (mandatory) call +to kobject_init():
void kobject_init(struct kobject *kobj, struct kobj_type *ktype);
diff --git a/lib/kobject.c b/lib/kobject.c index 58751bb..46fc865 100644 --- a/lib/kobject.c +++ b/lib/kobject.c @@ -307,6 +307,8 @@ EXPORT_SYMBOL(kobject_set_name); * This function will properly initialize a kobject such that it can then * be passed to the kobject_add() call. * + * The kobject must be initialized to zero prior to calling this function. + * * After this function is called, the kobject MUST be cleaned up by a call * to kobject_put(), not by a call to kfree directly to ensure that all of * the memory is cleaned up properly.
| |