From: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
To: Stephen Boyd <sboyd@kernel.org>
Cc: Michael Turquette <mturquette@baylibre.com>,
linux-kernel@vger.kernel.org, linux-clk@vger.kernel.org,
Bjorn Andersson <bjorn.andersson@linaro.org>
Subject: Re: [PATCH] clk: Evict unregistered clks from parent caches
Date: Tue, 27 Aug 2019 09:03:07 +0530 [thread overview]
Message-ID: <8e545af29789231be3a8b2e7b6ee7885@codeaurora.org> (raw)
In-Reply-To: <20190826234311.138147-1-sboyd@kernel.org>
On 2019-08-27 05:13, Stephen Boyd wrote:
> We leave a dangling pointer in each clk_core::parents array that has an
> unregistered clk as a potential parent when that clk_core pointer is
> freed by clk{_hw}_unregister(). It is impossible for the true parent of
> a clk to be set with clk_set_parent() once the dangling pointer is left
> in the cache because we compare parent pointers in
> clk_fetch_parent_index() instead of checking for a matching clk name or
> clk_hw pointer.
>
> Before commit ede77858473a ("clk: Remove global clk traversal on fetch
> parent index"), we would check clk_hw pointers, which has a higher
> chance of being the same between registration and unregistration, but
> it
> can still be allocated and freed by the clk provider. In fact, this has
> been a long standing problem since commit da0f0b2c3ad2 ("clk: Correct
> lookup logic in clk_fetch_parent_index()") where we stopped trying to
> compare clk names and skipped over entries in the cache that weren't
> NULL.
>
> There are good (performance) reasons to not do the global tree lookup
> in
> cases where the cache holds dangling pointers to parents that have been
> unregistered. Let's take the performance hit on the uncommon
> registration path instead. Loop through all the clk_core::parents
> arrays
> when a clk is unregistered and set the entry to NULL when the parent
> cache entry and clk being unregistered are the same pointer. This will
> fix this problem and avoid the overhead for the "normal" case.
>
> Based on a patch by Bjorn Andersson.
>
> Fixes: da0f0b2c3ad2 ("clk: Correct lookup logic in
> clk_fetch_parent_index()")
> Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
> Cc: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
> ---
> drivers/clk/clk.c | 30 ++++++++++++++++++++++++++++++
> 1 file changed, 30 insertions(+)
>
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index c0990703ce54..f3982bfa39d6 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -3737,6 +3737,34 @@ static const struct clk_ops clk_nodrv_ops = {
> .set_parent = clk_nodrv_set_parent,
> };
>
> +static void clk_core_evict_parent_cache_subtree(struct clk_core *root,
> + struct clk_core *target)
> +{
> + int i;
> + struct clk_core *child;
> +
> + for (i = 0; i < root->num_parents; i++)
> + if (root->parents[i].core == target)
> + root->parents[i].core = NULL;
> +
> + hlist_for_each_entry(child, &root->children, child_node)
> + clk_core_evict_parent_cache_subtree(child, target);
> +}
> +
> +/* Remove this clk from all parent caches */
> +static void clk_core_evict_parent_cache(struct clk_core *core)
> +{
> + struct hlist_head **lists;
> + struct clk_core *root;
> +
> + lockdep_assert_held(&prepare_lock);
> +
> + for (lists = all_lists; *lists; lists++)
> + hlist_for_each_entry(root, *lists, child_node)
> + clk_core_evict_parent_cache_subtree(root, core);
> +
> +}
> +
> /**
> * clk_unregister - unregister a currently registered clock
> * @clk: clock to unregister
> @@ -3775,6 +3803,8 @@ void clk_unregister(struct clk *clk)
> clk_core_set_parent_nolock(child, NULL);
> }
>
> + clk_core_evict_parent_cache(clk->core);
> +
> hlist_del_init(&clk->core->child_node);
>
> if (clk->core->prepare_count)
Thanks Stephen. Tested this on cheza now and the issue is not seen
anymore.
Tested-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member
of Code Aurora Forum, hosted by The Linux Foundation
next prev parent reply other threads:[~2019-08-27 3:33 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-26 23:43 [PATCH] clk: Evict unregistered clks from parent caches Stephen Boyd
2019-08-27 0:40 ` Bjorn Andersson
2019-08-27 3:33 ` Sai Prakash Ranjan [this message]
2019-08-27 10:28 ` kbuild test robot
2019-08-28 18:10 ` Stephen Boyd
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=8e545af29789231be3a8b2e7b6ee7885@codeaurora.org \
--to=saiprakash.ranjan@codeaurora.org \
--cc=bjorn.andersson@linaro.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mturquette@baylibre.com \
--cc=sboyd@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.