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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6C24DC00528 for ; Fri, 4 Aug 2023 22:24:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229870AbjHDWYJ (ORCPT ); Fri, 4 Aug 2023 18:24:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39002 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229582AbjHDWYG (ORCPT ); Fri, 4 Aug 2023 18:24:06 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 149A61704 for ; Fri, 4 Aug 2023 15:24:06 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id A74B362137 for ; Fri, 4 Aug 2023 22:24:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0DA61C433C7; Fri, 4 Aug 2023 22:24:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1691187845; bh=Fnt/9iWd4ZQ9T3UfZDA89bmlPIEv0uD6+RSSiVd+tZs=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=jkCQ1DAQ+8+kf+CVwwY5QyM5J3y9O+DXJmATvP5CVpPkfPwfkcgjkldMgnYP5/RAv 4aezNy43WzjOW8AgIO4YF2XJfLozeVUhIGn12OCVeEXLXSiAN29Bvdqn/2HPHHQotv ENF6xfgG50vA1KWBk5SuRnvhkhQhxQ9B2SqDNVAtGjB3+zW4M491vgUCUr1LPWIziP d0o+4XpI24HtcYjc/7M+U+b4xfCA8BKgjAPpyC0amzx8ePdD1wr9ZSc8qOqGR0bhx/ m38dZREAabj9CZLwo7x+1emVrEHHvQebrY5vWVtcaFUeezyLM8IQZcILarRVe2p9hu bPse2YmLMC9wQ== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1qS3DG-002Mjz-Kf; Fri, 04 Aug 2023 23:24:02 +0100 Date: Fri, 04 Aug 2023 23:24:02 +0100 Message-ID: <86cz025tvh.wl-maz@kernel.org> From: Marc Zyngier To: Andy Shevchenko Cc: Johan Hovold , linux-kernel@vger.kernel.org, Thomas Gleixner Subject: Re: [PATCH v1 1/1] irqdomain: Refactor error path in __irq_domain_alloc_fwnode() In-Reply-To: References: <20230804164932.40582-1-andriy.shevchenko@linux.intel.com> <84f2ea9ee0c08c8826c0f26c4a6291c9@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/28.2 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: andriy.shevchenko@linux.intel.com, johan+linaro@kernel.org, linux-kernel@vger.kernel.org, tglx@linutronix.de X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 04 Aug 2023 21:12:11 +0100, Andy Shevchenko wrote: > > On Fri, Aug 04, 2023 at 06:33:07PM +0100, Marc Zyngier wrote: > > On 2023-08-04 17:49, Andy Shevchenko wrote: > > > First of all, there is no need to call kasprintf() if the previous > > > allocation failed. Second, there is no need to call for kfree() > > > when we know that its parameter is NULL. Refactor the code accordingly. > > ... > > > > n = kasprintf(GFP_KERNEL, "irqchip@%pa", pa); > > > break; > > > } > > > - > > > - if (!fwid || !n) { > > > + if (!n) { > > > kfree(fwid); > > > - kfree(n); > > > return NULL; > > > } > > > > What are you trying to fix? > > I'm not trying to fix anything (there is no such statement from me), > but I would think of some micro-optimization (speedup boot for > unnoticeable time? Dunno.). Error handling paths rarely qualify as an optimisation. > > > We have a common error handling path, which makes it easy to > > track the memory management. I don't think this sort of bike > > shedding adds much to the maintainability of this code. > > Your call, of course, but I not often see in the kernel two or three attempts > to allocate some memory and have grouped check for the failure. Things like this[1]? Well, this is a pattern I use often enough. Maybe it isn't everybody's taste, but it suits me. M. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/irqchip/irq-gic-v3-its.c#n3438 -- Without deviation from the norm, progress is not possible.