Messages in this thread Patch in this message | | | Subject | Re: clk: rockchip: Checking a kmemdup() call in rockchip_clk_register_pll() | From | Markus Elfring <> | Date | Mon, 14 Oct 2019 09:26:41 +0200 |
| |
> The other option would be to panic, but the kernel should not > panic if other options are available - and continuing with a static > pll frequency is less invasive in the error case.
I would like to point out that this function implementation contains the following source code already.
… /* name the actual pll */ snprintf(pll_name, sizeof(pll_name), "pll_%s", name);
pll = kzalloc(sizeof(*pll), GFP_KERNEL); if (!pll) return ERR_PTR(-ENOMEM); …
… > +++ b/drivers/clk/rockchip/clk-pll.c > @@ -909,14 +909,16 @@ struct clk *rockchip_clk_register_pll(struct rockchip_clk_provider *ctx, … > - pll->rate_count = len; > pll->rate_table = kmemdup(rate_table, > pll->rate_count * > sizeof(struct rockchip_pll_rate_table), > GFP_KERNEL); > - WARN(!pll->rate_table, > - "%s: could not allocate rate table for %s\n", > - __func__, name); > + > + /* > + * Set num rates to 0 if kmemdup fails. That way the clock > + * at least can report its rate and stays usable. > + */ > + pll->rate_count = pll->rate_table ? len : 0;
Can an other error handling strategy make sense occasionally?
… if (!pll->rate_table) { clk_unregister(mux_clk); mux_clk = ERR_PTR(-ENOMEM); goto err_mux; } …
Would you like to adjust such exception handling another bit?
Regards, Markus
| |