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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A7EE6C636D7 for ; Tue, 21 Feb 2023 22:51:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Date:To:Cc:From:Subject:References: In-Reply-To:MIME-Version:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=JzEAjvhaj3+cncN59lE0U1zYHtjap9JV2AgaN5k53O0=; b=XV4BbPht/GTxpl eN4CaA+GR16lMEyB1S96C/zppXFMIjuOQCDzdie/uyNg1PQM9asfurVU9gEZ9ZXODSFkDQg/mwoVr tvbjng7y8bCuDbTj1opfAtSUxv1QHBUH5jVu5qVuWdBZ5CxqtO81TV7CaDwce2gL18O3ztcOslqRZ tDW4aez0qdfvjRoVrbB6/jv58EisdMseXLj3OzKLjLvkyeAOP4lbB1z/ArofZ9iaBx0uTgtWgo/uc SIUmTNxH31i7W802llWmVN5abj9TctSqOnfJ2FdZCNXlJOSQErGlHfKuzRR22Q5EbFJ7mlS3cImRq f/Rg8cr5VqHYbqL/K5eQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pUbSs-00A2me-Ob; Tue, 21 Feb 2023 22:50:26 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pUbSp-00A2ll-C6 for linux-arm-kernel@lists.infradead.org; Tue, 21 Feb 2023 22:50:24 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id D701B6108C; Tue, 21 Feb 2023 22:50:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3F856C433EF; Tue, 21 Feb 2023 22:50:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1677019822; bh=IffyvW5Atm7oajpsNnP6gCiCgyMk3+5BS2IJKL3o0MA=; h=In-Reply-To:References:Subject:From:Cc:To:Date:From; b=AsQX+GUgyy7zRxcMuAfCdV8miYVviuAgxpZ2zzQ2eWm+uSB/a+b6K+2riRB2NoPqU fY1TzpdSHX4PwzWioynKgI6bUzD68K95To239UJcR/Bfp2frBiu5aEUEjG9rp2kc+I OeTKnTnxy3MQI2WpmT6PvlMP0vmWmltP+AqHT90Oy5zVUnI+WOsUPHd21LXI6dib6F FZ0fFhAa27uB3Dp+fMPjiPyvt2ZloPfli4fdnsAjpvjodhU+Tmtw5ksjJjpjk1XxKl snMK30wXygF04U8XaCY7Dl+YkuhfLw2lC7MgPy54Ry2SsAgQomE9EsqXFZ2PXCgVL7 jnyasCashMzkg== Message-ID: <1e05156120fdfd79ed267f44fe7f3491.sboyd@kernel.org> MIME-Version: 1.0 In-Reply-To: <20230222215834.3507-1-zeming@nfschina.com> References: <20230222215834.3507-1-zeming@nfschina.com> Subject: Re: [PATCH] zynq: clkc: Add kmalloc allocation flag From: Stephen Boyd Cc: linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Li zeming To: Li zeming , michal.simek@xilinx.com, mturquette@baylibre.com Date: Tue, 21 Feb 2023 14:50:20 -0800 User-Agent: alot/0.10 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230221_145023_467905_F9962722 X-CRM114-Status: GOOD ( 17.92 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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 > --- > 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. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel