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 DEEFDC433F5 for ; Thu, 10 Mar 2022 09:02:26 +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:MIME-Version:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=J4pz2xFzK0vsOpxX7yPAmirjou4yVzUo0DidyDWpxco=; b=k2liawRO4efGYL PHIR2/lrEDG2dT71cGkj2wkdBaHchSjXMOg5UxU23gAeIuXiwXZ7vq0P8x1yOi3hXh0jchh7v+GCv Gc6QThe/w3Wqu+VPM5LgaoacnAjiy8Ghwb/naKryeGxoKQL9ywADuEV5lTCfMPWL+fwZUd60nFCNk DnAJkY1Kw23mQzctPAfgl6g9mmfDP718WQAnZdnTyRO+/Gu0HIT0u+BTDRqoUz/K6TPYvr2MOAILp 7u/Cbvw3gPve5onB0M7c/3xhjfk/o4AerNAWaD4BcAzgXFQPjaNhomehheOUhnWCRK3Kv0jB4dWki vNGH4sURubZjfjqS1EpA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nSEfW-00C2rX-LG; Thu, 10 Mar 2022 09:01:10 +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 1nSEfN-00C2pT-Kl for linux-arm-kernel@lists.infradead.org; Thu, 10 Mar 2022 09:01:08 +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 1138361C33; Thu, 10 Mar 2022 09:01:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 730DBC340E8; Thu, 10 Mar 2022 09:00:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1646902859; bh=IOzytD6gUTJGKdB6MM8m0HZeo4aGPw0Sww5Drf5mH0U=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Do5yGtd1FKYeZJwiwR9npGgS+HFeXi0INUaxHUx+g0sZZ9wPqC+KScm7FnPrCIwB5 MiAMfq6po0qTPDRgsUpC0uY8QD1902DLzK4YnYoUgXQBzmlGLBkhQEa7gH4Q43t/R3 FsYeeqEXoRwsBQyubmk4iui8yqK3mjHU3EkG6X9aroyIN9KxbnR4rLUe1w72bCJzQa 5C42/qtdMGPJg97b/iH1kWoXIx7jGKcQRdMU3cs9GaYYFIbOOVpE3AH1Pgg8cKuJoa E28WRnT6/7ODTPY2bDBZL1mad/0M2mVAs+lSi4NbCEP3JnFzncfYhApO1h/Am2/MOs XBaJohCEzx7vw== Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nSEfJ-00DWvj-1z; Thu, 10 Mar 2022 09:00:57 +0000 Date: Thu, 10 Mar 2022 09:00:56 +0000 Message-ID: <87pmmuyyev.wl-maz@kernel.org> From: Marc Zyngier To: Guo Zhengkui Cc: Hector Martin , Sven Peter , Alyssa Rosenzweig , Thomas Gleixner , "moderated list:ARM/APPLE MACHINE SUPPORT" , "open list:IRQCHIP DRIVERS" , "zhengkui_guo@outlook.com" Subject: Re: [PATCH] irqchip/apple-aic: application of sizeof() to a pointer In-Reply-To: References: <20220310050238.4478-1-guozhengkui@vivo.com> <87sfrqyzyr.wl-maz@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/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: guozhengkui@vivo.com, marcan@marcan.st, sven@svenpeter.dev, alyssa@rosenzweig.io, tglx@linutronix.de, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, zhengkui_guo@outlook.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220310_010105_499349_CF680CF4 X-CRM114-Status: GOOD ( 31.23 ) 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 On Thu, 10 Mar 2022 08:48:07 +0000, Guo Zhengkui wrote: > > On 2022/3/10 16:27, Marc Zyngier wrote: > > On Thu, 10 Mar 2022 05:02:38 +0000, > > Guo Zhengkui wrote: > >> > >> `ic->fiq_aff[fiq]` is a pointer to the unnamed struct. > >> `sizeof(ic->fiq_aff[fiq])` intends to get the size of this pointer. But > >> readers may get confused. `sizeof(unsigned long)` makes more sense because > >> `unsigned long` has the same size of pointer. > > > > More sense? It really depends on who reads the code. > > > >> > >> reference: > >> https://lore.kernel.org/all/Ya%2FeUbdN1+ABFVWf@rowland.harvard.edu/ > >> https://lore.kernel.org/all/YbBGGI9wQenI4kP7@kroah.com/ > >> https://lore.kernel.org/all/20211209062441.9856-1-guozhengkui@vivo.com/ > >> > >> Signed-off-by: Guo Zhengkui > >> --- > >> drivers/irqchip/irq-apple-aic.c | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/drivers/irqchip/irq-apple-aic.c b/drivers/irqchip/irq-apple-aic.c > >> index b40199c6625e..23098b469b1a 100644 > >> --- a/drivers/irqchip/irq-apple-aic.c > >> +++ b/drivers/irqchip/irq-apple-aic.c > >> @@ -810,7 +810,7 @@ static void build_fiq_affinity(struct aic_irq_chip *ic, struct device_node *aff) > >> if (WARN_ON(n < 0)) > >> return; > >> - ic->fiq_aff[fiq] = kzalloc(sizeof(ic->fiq_aff[fiq]), > >> GFP_KERNEL); > >> + ic->fiq_aff[fiq] = kzalloc(sizeof(unsigned long), GFP_KERNEL); > > > > And by doing that, you are making even more difficult to spot the > > glaring bug that is in front of your eyes: we're not trying to > > allocate a pointer, but to allocate the full data structure. > > > > Oh, I surely made a big mistake... Big mistake? No. You patch didn't change the behaviour of the code. But in the future, you want to pay more attention to what the author is trying to achieve: how is the data used, for example. Blindly generalising an advice given out of context often leads to bad patches. > > > Nothing went wrong as a 64bit allocation is plenty when you need at > > most 10 bits, but jeez, what a howler. I'm stashing the fixlet below > > on top. > > > > So, will you send this new patch by yourself? I've directly applied it[1]. Thanks, M. [1] https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/commit/?h=irq/irqchip-next&id=dc29812dbc873ae00bf19a4b8661984d7cce7a2e -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel