| Message ID | 20200124144154.v2.1.I7487325fe8e701a68a07d3be8a6a4b571eca9cfa@changeid (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Headers | show |
| Series | clk: qcom: Fix parenting for dispcc/gpucc/videocc | expand |
On Fri, Jan 24, 2020 at 02:42:16PM -0800, Douglas Anderson wrote: > When I got my clock parenting slightly wrong I ended up with a crash > that looked like this: > > Unable to handle kernel NULL pointer dereference at virtual > address 0000000000000000 > ... > pc : clk_hw_get_rate+0x14/0x44 > ... > Call trace: > clk_hw_get_rate+0x14/0x44 > _freq_tbl_determine_rate+0x94/0xfc > clk_rcg2_determine_rate+0x2c/0x38 > clk_core_determine_round_nolock+0x4c/0x88 > clk_core_round_rate_nolock+0x6c/0xa8 > clk_core_round_rate_nolock+0x9c/0xa8 > clk_core_set_rate_nolock+0x70/0x180 > clk_set_rate+0x3c/0x6c > of_clk_set_defaults+0x254/0x360 > platform_drv_probe+0x28/0xb0 > really_probe+0x120/0x2dc > driver_probe_device+0x64/0xfc > device_driver_attach+0x4c/0x6c > __driver_attach+0xac/0xc0 > bus_for_each_dev+0x84/0xcc > driver_attach+0x2c/0x38 > bus_add_driver+0xfc/0x1d0 > driver_register+0x64/0xf8 > __platform_driver_register+0x4c/0x58 > msm_drm_register+0x5c/0x60 > ... > > It turned out that clk_hw_get_parent_by_index() was returning NULL and > we weren't checking. Let's check it so that we don't crash. > > Fixes: ac269395cdd8 ("clk: qcom: Convert to clk_hw based provider APIs") > Signed-off-by: Douglas Anderson <dianders@chromium.org> > --- > I haven't gone back and tried to reproduce this same crash on older > kernels, but I'll put the blame on commit ac269395cdd8 ("clk: qcom: > Convert to clk_hw based provider APIs"). Before that if we got a NULL > parent back it was fine and dandy since a NULL "struct clk" is valid > to use but a NULL "struct clk_hw" is not. > > Changes in v2: > - Patch ("clk: qcom: rcg2: Don't crash...") new for v2. > > drivers/clk/qcom/clk-rcg2.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/clk/qcom/clk-rcg2.c b/drivers/clk/qcom/clk-rcg2.c > index da045b200def..9098001ac805 100644 > --- a/drivers/clk/qcom/clk-rcg2.c > +++ b/drivers/clk/qcom/clk-rcg2.c > @@ -218,6 +218,9 @@ static int _freq_tbl_determine_rate(struct clk_hw *hw, const struct freq_tbl *f, > > clk_flags = clk_hw_get_flags(hw); > p = clk_hw_get_parent_by_index(hw, index); > + if (!p) > + return -EINVAL; > + > if (clk_flags & CLK_SET_RATE_PARENT) { > rate = f->freq; > if (f->pre_div) { Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
diff --git a/drivers/clk/qcom/clk-rcg2.c b/drivers/clk/qcom/clk-rcg2.c index da045b200def..9098001ac805 100644 --- a/drivers/clk/qcom/clk-rcg2.c +++ b/drivers/clk/qcom/clk-rcg2.c @@ -218,6 +218,9 @@ static int _freq_tbl_determine_rate(struct clk_hw *hw, const struct freq_tbl *f, clk_flags = clk_hw_get_flags(hw); p = clk_hw_get_parent_by_index(hw, index); + if (!p) + return -EINVAL; + if (clk_flags & CLK_SET_RATE_PARENT) { rate = f->freq; if (f->pre_div) {
When I got my clock parenting slightly wrong I ended up with a crash that looked like this: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 ... pc : clk_hw_get_rate+0x14/0x44 ... Call trace: clk_hw_get_rate+0x14/0x44 _freq_tbl_determine_rate+0x94/0xfc clk_rcg2_determine_rate+0x2c/0x38 clk_core_determine_round_nolock+0x4c/0x88 clk_core_round_rate_nolock+0x6c/0xa8 clk_core_round_rate_nolock+0x9c/0xa8 clk_core_set_rate_nolock+0x70/0x180 clk_set_rate+0x3c/0x6c of_clk_set_defaults+0x254/0x360 platform_drv_probe+0x28/0xb0 really_probe+0x120/0x2dc driver_probe_device+0x64/0xfc device_driver_attach+0x4c/0x6c __driver_attach+0xac/0xc0 bus_for_each_dev+0x84/0xcc driver_attach+0x2c/0x38 bus_add_driver+0xfc/0x1d0 driver_register+0x64/0xf8 __platform_driver_register+0x4c/0x58 msm_drm_register+0x5c/0x60 ... It turned out that clk_hw_get_parent_by_index() was returning NULL and we weren't checking. Let's check it so that we don't crash. Fixes: ac269395cdd8 ("clk: qcom: Convert to clk_hw based provider APIs") Signed-off-by: Douglas Anderson <dianders@chromium.org> --- I haven't gone back and tried to reproduce this same crash on older kernels, but I'll put the blame on commit ac269395cdd8 ("clk: qcom: Convert to clk_hw based provider APIs"). Before that if we got a NULL parent back it was fine and dandy since a NULL "struct clk" is valid to use but a NULL "struct clk_hw" is not. Changes in v2: - Patch ("clk: qcom: rcg2: Don't crash...") new for v2. drivers/clk/qcom/clk-rcg2.c | 3 +++ 1 file changed, 3 insertions(+)