From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
To: Stephen Boyd <sboyd@codeaurora.org>
Cc: Mike Turquette <mturquette@linaro.org>,
Tomeu Vizoso <tomeu.vizoso@collabora.com>,
Emilio L??pez <emilio@elopez.com.ar>,
linux-samsung-soc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] clk: Don't dereference parent clock if is NULL
Date: Thu, 12 Feb 2015 14:35:55 +0100 [thread overview]
Message-ID: <54DCAC3B.8080309@collabora.co.uk> (raw)
In-Reply-To: <20150211185435.GD11190@codeaurora.org>
Hello Stephen,
Thanks a lot for your feedback.
On 02/11/2015 07:54 PM, Stephen Boyd wrote:
> On 02/11, Javier Martinez Canillas wrote:
>> --- a/drivers/clk/clk.c
>> +++ b/drivers/clk/clk.c
>> @@ -799,7 +799,7 @@ clk_mux_determine_rate_flags(struct clk_hw *hw, unsigned long rate,
>> /* if NO_REPARENT flag set, pass through to current parent */
>> if (core->flags & CLK_SET_RATE_NO_REPARENT) {
>> parent = core->parent;
>> - if (core->flags & CLK_SET_RATE_PARENT)
>> + if (core->flags & CLK_SET_RATE_PARENT && parent)
>> best = __clk_determine_rate(parent->hw, rate,
>> min_rate, max_rate);
>> else if (parent)
>
> Sorry this doesn't look right. Before all the recent changes to
> this file we would call __clk_round_rate() which would return 0
> if the first argument was NULL. Now we're going to take the else
> if path and do something different. So we need a parent ?
> parent->hw : NULL here.
>
Right, I'm not that familiar with the common clock framework so I
didn't realize I was changing the behavior, sorry about that...
> Of course, I wonder why a clock has the CLK_SET_RATE_PARENT flag
> set if it doesn't actually have a parent. That also seems wrong.
>
Yes, I did not face this issue and only patch #2 was enough to
fix my problem but the theoretical NULL pointer dereference
was found when reading the code.
I agree that a clock with that flag set should have at least one
parent but afaict there is no sanity check on clock registration.
And even if that was the case, I believe that the core should be
robust enough to check for NULL before trying to dereference it.
I'll post a v2 passing NULL as an argument and parent->hw if
parent is not NULL as you suggested.
Best regards,
Javier
next prev parent reply other threads:[~2015-02-12 13:36 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-11 10:13 [PATCH 0/2] clk: Some fixes for the per-user clk API changes Javier Martinez Canillas
2015-02-11 10:13 ` [PATCH 1/2] clk: Don't dereference parent clock if is NULL Javier Martinez Canillas
2015-02-11 18:54 ` Stephen Boyd
2015-02-12 13:35 ` Javier Martinez Canillas [this message]
2015-02-11 10:13 ` [PATCH 2/2] clk: composite: Set clk_core to composite rate and mux components Javier Martinez Canillas
2015-02-11 18:50 ` Stephen Boyd
2015-02-12 13:27 ` Javier Martinez Canillas
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=54DCAC3B.8080309@collabora.co.uk \
--to=javier.martinez@collabora.co.uk \
--cc=emilio@elopez.com.ar \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=mturquette@linaro.org \
--cc=sboyd@codeaurora.org \
--cc=tomeu.vizoso@collabora.com \
/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.