linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-kernel@vger.kernel.org
Cc: linux@roeck-us.net,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>
Subject: [PATCH 2/2] kobject: send KOBJ_REMOVE uevent when the object is removed from sysfs
Date: Sun, 24 May 2020 17:30:41 +0200	[thread overview]
Message-ID: <20200524153041.2361-2-gregkh@linuxfoundation.org> (raw)
In-Reply-To: <20200524153041.2361-1-gregkh@linuxfoundation.org>

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,
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.

Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 lib/kobject.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/lib/kobject.c b/lib/kobject.c
index 83198cb37d8d..2509e22ad74a 100644
--- a/lib/kobject.c
+++ b/lib/kobject.c
@@ -620,6 +620,13 @@ void kobject_del(struct kobject *kobj)
 	if (ktype)
 		sysfs_remove_groups(kobj, ktype->default_groups);
 
+	/* send "remove" if the caller did not do it but sent "add" */
+	if (kobj->state_add_uevent_sent && !kobj->state_remove_uevent_sent) {
+		pr_debug("kobject: '%s' (%p): auto cleanup 'remove' event\n",
+			 kobject_name(kobj), kobj);
+		kobject_uevent(kobj, KOBJ_REMOVE);
+	}
+
 	sysfs_remove_dir(kobj);
 	sysfs_put(sd);
 
@@ -673,13 +680,6 @@ static void kobject_cleanup(struct kobject *kobj)
 		pr_debug("kobject: '%s' (%p): does not have a release() function, it is broken and must be fixed. See Documentation/kobject.txt.\n",
 			 kobject_name(kobj), kobj);
 
-	/* send "remove" if the caller did not do it but sent "add" */
-	if (kobj->state_add_uevent_sent && !kobj->state_remove_uevent_sent) {
-		pr_debug("kobject: '%s' (%p): auto cleanup 'remove' event\n",
-			 kobject_name(kobj), kobj);
-		kobject_uevent(kobj, KOBJ_REMOVE);
-	}
-
 	/* 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",
-- 
2.26.2


  reply	other threads:[~2020-05-24 15:31 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 ` Greg Kroah-Hartman [this message]
2020-05-25 11:07   ` [PATCH 2/2] kobject: send KOBJ_REMOVE uevent when the object is removed from sysfs 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
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=20200524153041.2361-2-gregkh@linuxfoundation.org \
    --to=gregkh@linuxfoundation.org \
    --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).