From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: jorhand@linux.microsoft.com
Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>,
"Rafael J . Wysocki" <rafael@kernel.org>,
linux-kernel@vger.kernel.org, linux-next@vger.kernel.org
Subject: Re: [PATCH] software node: recursively unregister child swnodes
Date: Thu, 4 Jun 2020 22:15:23 +0200 [thread overview]
Message-ID: <20200604201523.GA1308830@kroah.com> (raw)
In-Reply-To: <20200604193623.16946-1-jorhand@linux.microsoft.com>
On Thu, Jun 04, 2020 at 12:36:23PM -0700, jorhand@linux.microsoft.com wrote:
> From: Jordan Hand <jorhand@linux.microsoft.com>
>
> If a child swnode is unregistered after it's parent, it can lead to
> undefined behavior.
Crashing the system is not really "undefined" :)
> When a swnode is unregistered, recursively free it's children to avoid
> this condition.
Are you sure? Why would you be unregistering a child after it's parent?
Why not just do not do that?
>
> Signed-off-by: Jordan Hand <jorhand@linux.microsoft.com>
> ---
> drivers/base/swnode.c | 13 ++++++++-----
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
> index e5eb27375416..e63093b1542b 100644
> --- a/drivers/base/swnode.c
> +++ b/drivers/base/swnode.c
> @@ -619,6 +619,8 @@ static void software_node_release(struct kobject *kobj)
> property_entries_free(swnode->node->properties);
> kfree(swnode->node);
> }
> +
> + list_del(&kobj->entry);
> ida_destroy(&swnode->child_ids);
> kfree(swnode);
> }
> @@ -712,11 +714,6 @@ EXPORT_SYMBOL_GPL(software_node_register_nodes);
> * @nodes: Zero terminated array of software nodes to be unregistered
> *
> * Unregister multiple software nodes at once.
> - *
> - * NOTE: Be careful using this call if the nodes had parent pointers set up in
> - * them before registering. If so, it is wiser to remove the nodes
> - * individually, in the correct order (child before parent) instead of relying
> - * on the sequential order of the list of nodes in the array.
> */
> void software_node_unregister_nodes(const struct software_node *nodes)
> {
> @@ -839,10 +836,16 @@ EXPORT_SYMBOL_GPL(fwnode_create_software_node);
> void fwnode_remove_software_node(struct fwnode_handle *fwnode)
> {
> struct swnode *swnode = to_swnode(fwnode);
> + struct swnode *child = NULL;
>
> if (!swnode)
> return;
>
> + while (!list_empty(&swnode->children)) {
> + child = list_first_entry_or_null(&swnode->children, struct swnode, entry);
> + fwnode_remove_software_node(&child->fwnode);
You should document that you just changed the behaivor here, as you are
now really doing fwnode_remove_software_node_and_all_children().
but again, why? Who wants to unregister a child before a parent?
thanks,
greg k-h
next prev parent reply other threads:[~2020-06-04 20:15 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-04 19:36 [PATCH] software node: recursively unregister child swnodes jorhand
2020-06-04 20:15 ` Greg Kroah-Hartman [this message]
2020-06-04 20:57 ` Jordan Hand
2020-06-04 23:28 ` Jordan Hand
2020-06-05 7:54 ` Greg Kroah-Hartman
2020-06-05 16:20 ` Jordan Hand
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=20200604201523.GA1308830@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=jorhand@linux.microsoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--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).