From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: linux-kernel@vger.kernel.org, Guenter Roeck <linux@roeck-us.net>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
Heikki Krogerus <heikki.krogerus@linux.intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>
Subject: Re: [PATCH 2/2] kobject: send KOBJ_REMOVE uevent when the object is removed from sysfs
Date: Wed, 27 May 2020 16:34:38 +0200 [thread overview]
Message-ID: <122364223.sG7U4uvVph@kreacher> (raw)
In-Reply-To: <2407984.idRd5kzSG0@kreacher>
On Wednesday, May 27, 2020 11:01:16 AM CEST Rafael J. Wysocki wrote:
> On Wednesday, May 27, 2020 10:34:51 AM CEST Rafael J. Wysocki wrote:
> > On Wed, May 27, 2020 at 9:50 AM Heikki Krogerus
> > <heikki.krogerus@linux.intel.com> wrote:
> > >
> > > On Tue, May 26, 2020 at 10:26:23AM +0200, Rafael J. Wysocki wrote:
> > > > On Tue, May 26, 2020 at 7:58 AM Greg Kroah-Hartman
> > > > <gregkh@linuxfoundation.org> wrote:
> > > > >
> > > > > On Mon, May 25, 2020 at 03:49:01PM -0700, Dmitry Torokhov wrote:
> > > > > > On Sun, May 24, 2020 at 8:34 AM Greg Kroah-Hartman
> > > > > > <gregkh@linuxfoundation.org> wrote:
> > > > > > >
> > > > > > > It is possible for a KOBJ_REMOVE uevent to be sent to userspace way
> > > > > > > after the files are actually gone from sysfs, due to how reference
> > > > > > > counting for kobjects work. This should not be a problem, but it would
> > > > > > > be good to properly send the information when things are going away, not
> > > > > > > at some later point in time in the future.
> > > > > > >
> > > > > > > Before this move, if a kobject's parent was torn down before the child,
> > > > > >
> > > > > > ^^^^ And this is the root of the problem and what has to be fixed.
> > > > >
> > > > > I fixed that in patch one of this series. Turns out the user of the
> > > > > kobject was not even expecting that to happen.
> > > > >
> > > > > > > when the call to kobject_uevent() happened, the parent walk to try to
> > > > > > > reconstruct the full path of the kobject could be a total mess and cause
> > > > > > > crashes. It's not good to try to tear down a kobject tree from top
> > > > > > > down, but let's at least try to not to crash if a user does so.
> > > > > >
> > > > > > One can try, but if we keep proper reference counting then kobject
> > > > > > core should take care of actually releasing objects in the right
> > > > > > order. I do not think you should keep this patch, and instead see if
> > > > > > we can push call to kobject_put(kobj->parent) into kobject_cleanup().
> > > > >
> > > > > I tried that, but there was a _lot_ of underflow errors reported, so
> > > > > there's something else happening. Or my attempt was incorrect :)
> > > >
> > > > So it looks like there is something in there that's been overlooked so far.
> > > >
> > > > I'll try to look at the Guenter's traces and figure out what went
> > > > wrong after the Heikki's patch.
> > >
> > > At least one problem with that patch was that I was releasing the
> > > parent reference unconditionally.
> >
> > That actually may be sufficient to explain all of the problems introduced by it.
>
> So Guenter, can you please test the patch below
Which can also be done without adding the second local var in kobject_cleanup(),
as follows.
> to see if it still introduces the problems seen by you on ARM?
---
From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Subject: [PATCH] kobject: Make sure the parent does not get released before its children
In the function kobject_cleanup(), kobject_del(kobj) is
called before the kobj->release(). That makes it possible to
release the parent of the kobject before the kobject itself.
To fix that, adding function __kboject_del() that does
everything that kobject_del() does except release the parent
reference. kobject_cleanup() then calls __kobject_del()
instead of kobject_del(), and separately decrements the
reference count of the parent kobject after kobj->release()
has been called.
Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Reported-by: kernel test robot <rong.a.chen@intel.com>
Fixes: 7589238a8cf3 ("Revert "software node: Simplify software_node_release() function"")
Suggested-by: "Rafael J. Wysocki" <rafael@kernel.org>
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
[ rjw: Drop parent reference only when called __kobject_del() ]
Signed-off-by: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
---
lib/kobject.c | 33 +++++++++++++++++++++++----------
1 file changed, 23 insertions(+), 10 deletions(-)
Index: linux-pm/lib/kobject.c
===================================================================
--- linux-pm.orig/lib/kobject.c
+++ linux-pm/lib/kobject.c
@@ -599,14 +599,7 @@ out:
}
EXPORT_SYMBOL_GPL(kobject_move);
-/**
- * kobject_del() - Unlink kobject from hierarchy.
- * @kobj: object.
- *
- * This is the function that should be called to delete an object
- * successfully added via kobject_add().
- */
-void kobject_del(struct kobject *kobj)
+static void __kobject_del(struct kobject *kobj)
{
struct kernfs_node *sd;
const struct kobj_type *ktype;
@@ -625,9 +618,23 @@ void kobject_del(struct kobject *kobj)
kobj->state_in_sysfs = 0;
kobj_kset_leave(kobj);
- kobject_put(kobj->parent);
kobj->parent = NULL;
}
+
+/**
+ * kobject_del() - Unlink kobject from hierarchy.
+ * @kobj: object.
+ *
+ * This is the function that should be called to delete an object
+ * successfully added via kobject_add().
+ */
+void kobject_del(struct kobject *kobj)
+{
+ struct kobject *parent = kobj->parent;
+
+ __kobject_del(kobj);
+ kobject_put(parent);
+}
EXPORT_SYMBOL(kobject_del);
/**
@@ -663,6 +670,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;
@@ -684,7 +692,10 @@ static void kobject_cleanup(struct kobje
if (kobj->state_in_sysfs) {
pr_debug("kobject: '%s' (%p): auto cleanup kobject_del\n",
kobject_name(kobj), kobj);
- kobject_del(kobj);
+ __kobject_del(kobj);
+ } else {
+ /* avoid dropping the parent reference unnecessarily */
+ parent = NULL;
}
if (t && t->release) {
@@ -698,6 +709,8 @@ static void kobject_cleanup(struct kobje
pr_debug("kobject: '%s': free name\n", name);
kfree_const(name);
}
+
+ kobject_put(parent);
}
#ifdef CONFIG_DEBUG_KOBJECT_RELEASE
next prev parent reply other threads:[~2020-05-27 14:34 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-24 15:30 [PATCH 1/2] software node: implement software_node_unregister() Greg Kroah-Hartman
2020-05-24 15:30 ` [PATCH 2/2] kobject: send KOBJ_REMOVE uevent when the object is removed from sysfs Greg Kroah-Hartman
2020-05-25 11:07 ` Rafael J. Wysocki
2020-05-25 22:49 ` Dmitry Torokhov
2020-05-26 5:58 ` Greg Kroah-Hartman
2020-05-26 8:26 ` Rafael J. Wysocki
2020-05-27 7:50 ` Heikki Krogerus
2020-05-27 8:34 ` Rafael J. Wysocki
2020-05-27 9:01 ` Rafael J. Wysocki
2020-05-27 14:34 ` Rafael J. Wysocki [this message]
2020-05-27 22:25 ` Guenter Roeck
2020-05-28 10:57 ` Rafael J. Wysocki
2020-05-28 13:56 ` Guenter Roeck
2020-05-28 14:03 ` Rafael J. Wysocki
2020-05-24 16:43 ` [PATCH 1/2] software node: implement software_node_unregister() Guenter Roeck
2020-05-25 2:44 ` Randy Dunlap
2020-05-25 7:59 ` Petr Mladek
2020-05-25 11:24 ` Heikki Krogerus
2020-05-26 0:12 ` Randy Dunlap
2020-05-28 20:25 ` Brendan Higgins
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=122364223.sG7U4uvVph@kreacher \
--to=rjw@rjwysocki.net \
--cc=dmitry.torokhov@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=rafael@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).