[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141005202843.GA1282@kroah.com>
Date: Sun, 5 Oct 2014 13:28:43 -0700
From: Greg KH <gregkh@...uxfoundation.org>
To: Jason Noakes <jjnoakes@...il.com>
Cc: linux-kernel@...r.kernel.org
Subject: Re: kobject_init and the zeroed-out-memory requirement
On Sun, Oct 05, 2014 at 04:02:14PM -0400, Jason Noakes wrote:
> I noticed that kobject_init() requres the kobject passed in to be zeroed out
> fully first.
That is because people were trying to reuse objects without destroying
them first. So try to detect this and prevent the developer from doing
something "foolish" like this.
Is there any in-kernel code that does not properly zero out the memory
before calling kobject_init()?
> 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 :)
> Documentation/kobject.txt does not mention the requirement that the memory be
> zero-initialized before it is passed to kobject_init.
>
> I would like to submit a patch - which solution is preferred?
>
> (a) Update Documentation/kobject.txt and explicitly add the requirement
> (b) Modify kobject_init to zero out the memory itself like other *_init
> routines
> (It already initializes most of its members - just not all of them)
As mentioned above, this is not going to be ok, look at the third if
statement in kobject_init() for why not.
> (c) Something else?
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.
hope this helps,
greg k-h
--
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/
Powered by blists - more mailing lists