From: Jordan Hand <jorhand@linux.microsoft.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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 13:57:01 -0700 [thread overview]
Message-ID: <c6150824-60d3-11ad-ba1a-e75d6a7a916e@linux.microsoft.com> (raw)
In-Reply-To: <20200604201523.GA1308830@kroah.com>
On 6/4/20 1:15 PM, Greg Kroah-Hartman wrote:
> 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" :)
Fair point :)
>
>> 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?
>
The main motivation for doing this was to support
`software_node_unregister_nodes` so that the passed list of nodes does
not need to be ordered in any particular way.
I suppose another way to do this would be to add a new function
`fwnode_remove_software_node_recursive` and just call that from
`software_node_unregister_nodes`.
That said, I suppose just ordering the nodes so that children come
before parents would also be fine. My thinking was just that accepting
any node ordering is simpler.
Thanks,
Jordan
next prev parent reply other threads:[~2020-06-04 20:57 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
2020-06-04 20:57 ` Jordan Hand [this message]
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=c6150824-60d3-11ad-ba1a-e75d6a7a916e@linux.microsoft.com \
--to=jorhand@linux.microsoft.com \
--cc=gregkh@linuxfoundation.org \
--cc=heikki.krogerus@linux.intel.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).