Cc: Kernel development list <linux-kernel@...>, Kay Sievers <kay.sievers@...>, Jonathan Corbet <corbet@...>, Randy Dunlap <randy.dunlap@...>, Cornelia Huck <cornelia.huck@...>
You don't need to set kset, do you? Or parent -- especially if kset is
set instead. Certainly kobjects without one or the other of those are
useful.
IMO it's better to let people know up front. Otherwise they might get
some misconception fixed in their brain, misdesign their drivers, and
have to change a large hunk of code when they discover it doesn't work
at runtime.
That's the whole point of documentation in the first place, right? To
tell people how the code is supposed to be used.
Let's see. The error scenario you propose is that a loadable module
contains a static kobject and the kobject's refcount is still positive
when the module is unloaded. Then the holder of the remaining
reference tries to access the kobject and crashes. Yes, that's bad.
But turn it around: Suppose the kobject were allocated dynamically
instead. It would remain in memory when the owning module was
unloaded, but its release method would go away along with the rest of
the module. When the last remaining reference is dropped there would
be a crash anyway.
Evidently the bug here is allowing the module to be unloaded while one
of its kobjects still has a positive refcount. It doesn't matter
whether the kobject was allocated statically or dynamically.
What about static kobjects in built-in (non-modular) kernel code?
Especially if the kobject in question is never released?
Alan Stern
-
