From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B27F4C10F14 for ; Tue, 15 Oct 2019 20:29:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5F28720872 for ; Tue, 15 Oct 2019 20:29:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728295AbfJOU3M convert rfc822-to-8bit (ORCPT ); Tue, 15 Oct 2019 16:29:12 -0400 Received: from gloria.sntech.de ([185.11.138.130]:39494 "EHLO gloria.sntech.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727994AbfJOU3L (ORCPT ); Tue, 15 Oct 2019 16:29:11 -0400 Received: from remote.shanghaihotelholland.com ([46.44.148.63] helo=phil.localnet) by gloria.sntech.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iKTRI-00086W-DK; Tue, 15 Oct 2019 22:29:04 +0200 From: Heiko Stuebner To: Markus Elfring Cc: linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, kernel-janitors@vger.kernel.org, Michael Turquette , Stephen Boyd , Aditya Pakki , Kangjie Lu , Navid Emamdoost , Stephen McCamant , LKML Subject: Re: clk: rockchip: Checking a kmemdup() call in rockchip_clk_register_pll() Date: Tue, 15 Oct 2019 22:29:03 +0200 Message-ID: <5173392.uhhkXBHGmO@phil> In-Reply-To: <45588ab8-2a6c-3f29-61ff-bccf8d6fb291@web.de> References: <2588953.0pqkEXWxhN@phil> <45588ab8-2a6c-3f29-61ff-bccf8d6fb291@web.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT Content-Type: text/plain; charset="UTF-8" Sender: linux-clk-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-clk@vger.kernel.org Am Montag, 14. Oktober 2019, 09:26:41 CEST schrieb Markus Elfring: > > 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? Nope. The big difference is that clocks rely heavily on their names to establish the clock tree parentship. So the PLL cannot work without the name but can provide some means of functionality without the rate-table especially as bootloaders do generally initialize a PLL to some form of sane frequency. Heiko