Message ID | 20230222215834.3507-1-zeming@nfschina.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp1692960wrn; Mon, 20 Feb 2023 21:52:23 -0800 (PST) X-Google-Smtp-Source: AK7set+3pJD9CBCNn1+VCIpORxJckwYSQYPZ8HB1fHoSmp45UGGzCjJLqD+9lIgJvq9G2XERYlzw X-Received: by 2002:a17:902:d4c8:b0:19a:6ec0:50c2 with SMTP id o8-20020a170902d4c800b0019a6ec050c2mr6050725plg.26.1676958743279; Mon, 20 Feb 2023 21:52:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1676958743; cv=none; d=google.com; s=arc-20160816; b=tEW6VHxaTgS/1tiqHk+CRLVy2Oj8rXJAbNBjbx6/g9/ZWhd09br5OZ7a1izkjpM4fE cuaBH9PghROvi+0OTSksrj751cXuJICqE/aKwmVfKfx0FAGAmBKiaWFv+dZnMFubnYHk a2FRfHjz3zYjZI/0d4H0NGsbvEmJHHzlfCjps7LvNdv08cU3ka6waLAyF5WqxdaLVDEq XVDK8006tobZiWI2y3ZZcqelwfJpBkyfMTKTxY4hhfCmJSeXFKtDeToJwHBDaqabBrzE WbTvZUIPam24NEPJIGt3viOXbx+YoS/frp9iej4q8KEZLNU5FXvzumnOmkXHl71nqse5 zPRQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:date:subject:cc:to:from; bh=lNJEdrcJAJWIO7S7/5V6kjvxTrMCn1mTUczToigqWzM=; b=fqG1w9cpGew1bdQF9PsznMSgoLQBMs+LWrsQ2dvTyNwiVUAQHJxJFhdWd4qj1SICgo ZIgElzUhTLak95KPpyRFgbZPa9FXn3rs5aaR2LMCRjXnBC7vlky2dMakvpRj9/wi5EAX 3Fyz0NRQ2rtW58OXNmD4bGcOlVxVJ4w6kRMLzjNxhCuyjnsU6iGtp2eip6Bf0V12u0jv E6yjbtm6musFo2khBYS/FpNIYhbCeQ8l+Tuob8pgsYV2xe83JkZgzy/IhkP6N8+k3AEc OWDt0tSj8r1ZibiFyxSb0ecS9tAz4FMnqabD3zKL95hLtMAkq+9TQFdDkSTiE63GOSJe g0vg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 19-20020a170902c21300b0019644d4246csi11147398pll.418.2023.02.20.21.52.09; Mon, 20 Feb 2023 21:52:23 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232955AbjBUF1U (ORCPT <rfc822;kautuk.consul.80@gmail.com> + 99 others); Tue, 21 Feb 2023 00:27:20 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43720 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232556AbjBUF1S (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 21 Feb 2023 00:27:18 -0500 Received: from mail.nfschina.com (unknown [42.101.60.237]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9B09A1C7FF; Mon, 20 Feb 2023 21:27:17 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mail.nfschina.com (Postfix) with ESMTP id CD4D81A009F1; Tue, 21 Feb 2023 13:27:54 +0800 (CST) X-Virus-Scanned: amavisd-new at nfschina.com Received: from mail.nfschina.com ([127.0.0.1]) by localhost (localhost.localdomain [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRel6M8OWtfb; Tue, 21 Feb 2023 13:27:54 +0800 (CST) Received: from localhost.localdomain (unknown [219.141.250.2]) (Authenticated sender: zeming@nfschina.com) by mail.nfschina.com (Postfix) with ESMTPA id EB0271A009BB; Tue, 21 Feb 2023 13:27:53 +0800 (CST) From: Li zeming <zeming@nfschina.com> To: mturquette@baylibre.com, sboyd@kernel.org, michal.simek@xilinx.com Cc: linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Li zeming <zeming@nfschina.com> Subject: [PATCH] zynq: clkc: Add kmalloc allocation flag Date: Thu, 23 Feb 2023 05:58:34 +0800 Message-Id: <20230222215834.3507-1-zeming@nfschina.com> X-Mailer: git-send-email 2.18.2 X-Spam-Status: No, score=0.9 required=5.0 tests=BAYES_00,DATE_IN_FUTURE_24_48, RDNS_NONE,SPF_HELO_NONE,SPF_NONE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1758418691135452332?= X-GMAIL-MSGID: =?utf-8?q?1758418691135452332?= |
Series |
zynq: clkc: Add kmalloc allocation flag
|
|
Commit Message
Li zeming
Feb. 22, 2023, 9:58 p.m. UTC
The kmalloc could crash if allocation fails. Add the __GFP_NOFAIL flag
to ensure that allocation succeeds every time.
Signed-off-by: Li zeming <zeming@nfschina.com>
---
drivers/clk/zynq/clkc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
Quoting Li zeming (2023-02-22 13:58:34) > The kmalloc could crash if allocation fails. Add the __GFP_NOFAIL flag > to ensure that allocation succeeds every time. > > Signed-off-by: Li zeming <zeming@nfschina.com> > --- > drivers/clk/zynq/clkc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/clk/zynq/clkc.c b/drivers/clk/zynq/clkc.c > index 7bdeaff2bfd6..7621c2f00468 100644 > --- a/drivers/clk/zynq/clkc.c > +++ b/drivers/clk/zynq/clkc.c > @@ -427,7 +427,7 @@ static void __init zynq_clk_setup(struct device_node *np) > SLCR_GEM1_CLK_CTRL, 0, 0, &gem1clk_lock); > > tmp = strlen("mio_clk_00x"); > - clk_name = kmalloc(tmp, GFP_KERNEL); > + clk_name = kmalloc(tmp, GFP_KERNEL | __GFP_NOFAIL); There are so many more allocations happening in this function and they aren't marked nofail. Why is this one special? I could see a patch moving mio_clk_00x to the stack and then printing to it. But it is also fine like this, so I don't see any reason to change this.
hello senior: I observed that some other variable assignments in this function are basically judged by the if statement, while clk_name does not make an if branch statement, and I think clk_name is also relatively important, increasing __GFP_NOFAIL flag ensures that the assignment can succeed under any circumstances.
Hi, On 2/23/23 19:33, Li zeming wrote: > > hello senior: > I observed that some other variable assignments in this function are basically judged by the if statement, while clk_name does not make an if branch statement, and I think clk_name is also relatively important, increasing __GFP_NOFAIL flag ensures that the assignment can succeed under any circumstances. > I think that solution with array on stack would be better choice. It will be faster and you can completely skip the whole allocation code for it. Thanks, Michal
diff --git a/drivers/clk/zynq/clkc.c b/drivers/clk/zynq/clkc.c index 7bdeaff2bfd6..7621c2f00468 100644 --- a/drivers/clk/zynq/clkc.c +++ b/drivers/clk/zynq/clkc.c @@ -427,7 +427,7 @@ static void __init zynq_clk_setup(struct device_node *np) SLCR_GEM1_CLK_CTRL, 0, 0, &gem1clk_lock); tmp = strlen("mio_clk_00x"); - clk_name = kmalloc(tmp, GFP_KERNEL); + clk_name = kmalloc(tmp, GFP_KERNEL | __GFP_NOFAIL); for (i = 0; i < NUM_MIO_PINS; i++) { int idx;