On Wed, Apr 15, 2020 at 10:47 AM Heikki Krogerus heikki.krogerus@linux.intel.com wrote:
Hi Greg,
On Wed, Apr 15, 2020 at 08:11:54AM +0200, Greg KH wrote:
diff --git a/lib/kobject.c b/lib/kobject.c index 83198cb37d8d..5921e2470b46 100644 --- a/lib/kobject.c +++ b/lib/kobject.c @@ -663,6 +663,7 @@ EXPORT_SYMBOL(kobject_get_unless_zero); */ static void kobject_cleanup(struct kobject *kobj) {
- struct kobject *parent = kobj->parent; struct kobj_type *t = get_ktype(kobj); const char *name = kobj->name;
@@ -680,6 +681,9 @@ static void kobject_cleanup(struct kobject *kobj) kobject_uevent(kobj, KOBJ_REMOVE); }
- /* make sure the parent is not released before the (last) child */
- kobject_get(parent);
- /* remove from sysfs if the caller did not do it */ if (kobj->state_in_sysfs) { pr_debug("kobject: '%s' (%p): auto cleanup kobject_del\n",
@@ -693,6 +697,8 @@ static void kobject_cleanup(struct kobject *kobj) t->release(kobj); }
- kobject_put(parent);
No, please don't do this.
A child device should have always incremented the parent already if it was correctly registered. We have had this patch been proposed multiple times over the years, and every time it was, we said no and went and fixed the real issue which was with the user of the interface.
The parent ref count is incremented by the child, that is not the problem. The problem is that when that child is released, if it's the last child of the parent, and there are no other users for the parent, then the parent is actually released _before_ the child. And that happens in the above function kobject_cleanup().
In fact, it happens in kobject_del() invoked by kobject_cleanup() AFAICS.
So it appears incorrect to use kobject_del() as is in the latter.
We can work around the problem by taking a reference to the parent separately, but we have to do that everywhere separately (which I guess is exactly what has been done so far). That workaroud still does not really fix the core problem. The core problem is still that lib/kboject.c is allowing the parent kobject to be released before the child kobject, and that quite simply should not be allowed to happen.
I don't have a problem if you want to have a better solution for this, but the solution really can't anymore be that we are always expected to separately increment the parent's ref count with every type of kobject.
An alternative might be to define something like __kobject_del() doing everything that kobject_del() does *without* the kobject_put(kobj->parent).
Then, kobject_del() could be defined as something like (pseudocode):
kobject_del(kobj) { kobject *perent = kobj->parent;
__kobject_del(kobj); kobject_put(parent); }
and kobject_cleanup() could call __kobject_del() instead of kobject_del() and then do the last kobject_put(parent) when it is done with the child.
Would that work?