Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1230164imu; Wed, 16 Jan 2019 15:16:00 -0800 (PST) X-Google-Smtp-Source: ALg8bN6TthrGtl+5ChrURjlUAOX+PwdROXOtw2tOWe1yCrQlxlnxN0GNM692ui9L6vTMNE2jx4F2 X-Received: by 2002:a62:37c3:: with SMTP id e186mr12580358pfa.251.1547680559934; Wed, 16 Jan 2019 15:15:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547680559; cv=none; d=google.com; s=arc-20160816; b=r3qvzfhRalGGJcHLv0mIrHoZ/VuWjIoaP+MMl0XhLwgkV+XDwj1S+yxMAZ69klTi2K uthTgfGaBSM/KMVJiF/9refj6Yb44I1klL6kiqo7W3a3qN2VT9cCY0fTlNGp2a1WYZ2Z O/dKztIhoZXg63kVzkS4twKUuE+7pbpIDXqF7KpkqYEbfnwr8A8JqytSdPrOO1Gio9BJ 4gK3XkQopO0yg+WWsh8bHCNJLYzBhSc0aGn52n6nQJEjebGibF7EtsVhHxf8853xBEGz rjmLX6pzxuHgWRPOucmK7r82DlHSemd9MFoKVnAtW97fTVsytohXyyVa+g8iekicb1ZW oF5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=HjB4WyTG0y963TSzDm2EKwD/+zJ5pPanwxddC7G0mTw=; b=tjGLLlzd403zFqM0j4pnG5zSA2hPzzmBzkikBqDqLiALYc6vLRZdH4THso6i36Pixg NVQJRVTiIS9386omyOyoN4MbpjqtRdfdZN2R8Ab8UBnFYZBMo0QCDO+sFHNe+/LPWo8y oTxMnhT7k1smJlX4IlxS7sXDJoHij8O6qIiu017tZr6xKNRbQXgX/xX0cKvJU+1lbY45 KfukbpmZ8keARo/ZpfaXCIoijrM3o4lYZ6HBbEUZpcuL3pjjGI08dT47KkdxQqEXL5zT RTkCJKK1cV/S7W7v12Z8hyXpGrhXjGM7VP3nM+Qf3KSZFECzbQUy2hsZCTLBawvSg3Za FEBg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=ejGwBCRo; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d37si7730672plb.140.2019.01.16.15.15.41; Wed, 16 Jan 2019 15:15:59 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=ejGwBCRo; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2405753AbfAPRVS (ORCPT + 99 others); Wed, 16 Jan 2019 12:21:18 -0500 Received: from merlin.infradead.org ([205.233.59.134]:40694 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727015AbfAPRVS (ORCPT ); Wed, 16 Jan 2019 12:21:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=HjB4WyTG0y963TSzDm2EKwD/+zJ5pPanwxddC7G0mTw=; b=ejGwBCRoKP4jizHf4jljpbq8Ge ocCCBkkxl47KYLXCdgdiSlP1dPQ4T+/v7X9oPIF96L33/f6dIitqjyFlq0jNCV2n7uDwd9bcp5gcu 1CmaOIU+Hz15IHxd+zAJc4JWyEOQzUJCFr64ukBPVoMOvn6B66p3jrlLgYdx/Fs7TMSMvTAbH1827 TQL888u1TxkBcoqcj5Mc8C6ZQSSiwIo2pynIwahqkRuXq6a6lUs2+czBg+iHGFb5nxpvsV93YVz8D 2KRhJFDorEc5PSVa7knXcLCqEkAap6W/kCR7dyMgPqJ808vj9ZJ79fmvbIeyLjncdF18CEl1YnEcb y+oADF8A==; Received: from [199.233.58.37] (helo=[10.83.93.157]) by merlin.infradead.org with esmtpsa (Exim 4.90_1 #2 (Red Hat Linux)) id 1gjosL-0002gO-7t; Wed, 16 Jan 2019 17:21:13 +0000 Subject: Re: [PATCH] powerpc/ps3: Use struct_size() in kzalloc() To: "Gustavo A. R. Silva" , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org References: <20190108210010.GA980@embeddedor> From: Geoff Levand Message-ID: <595f7b4b-9e26-ae72-de5f-270dce677c65@infradead.org> Date: Wed, 16 Jan 2019 09:21:12 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20190108210010.GA980@embeddedor> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Gustavo, On 1/8/19 1:00 PM, Gustavo A. R. Silva wrote: > One of the more common cases of allocation size calculations is finding the > size of a structure that has a zero-sized array at the end, along with memory > for some number of elements for that array. For example: > > struct foo { > int stuff; > void *entry[]; > }; > > instance = kzalloc(sizeof(struct foo) + sizeof(void *) * count, GFP_KERNEL); > > Instead of leaving these open-coded and prone to type mistakes, we can now > use the new struct_size() helper: > > instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL); > > This code was detected with the help of Coccinelle. > > Signed-off-by: Gustavo A. R. Silva > --- > arch/powerpc/platforms/ps3/device-init.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/arch/powerpc/platforms/ps3/device-init.c b/arch/powerpc/platforms/ps3/device-init.c > index e7075aaff1bb..59587b75493d 100644 > --- a/arch/powerpc/platforms/ps3/device-init.c > +++ b/arch/powerpc/platforms/ps3/device-init.c > @@ -354,9 +354,7 @@ static int ps3_setup_storage_dev(const struct ps3_repository_device *repo, > repo->dev_index, repo->dev_type, port, blk_size, num_blocks, > num_regions); > > - p = kzalloc(sizeof(struct ps3_storage_device) + > - num_regions * sizeof(struct ps3_storage_region), > - GFP_KERNEL); > + p = kzalloc(struct_size(p, regions, num_regions), GFP_KERNEL); > if (!p) { > result = -ENOMEM; > goto fail_malloc; It seems to me the motivation for this change is just to have a code change. As I've said for other similar patches, I'm reluctant to accept such trivial changes to the PS3 code because it makes it harder for me to maintain the code in the long term. When I need to do a git bisect to track down a problem I generally have a set of debugging patches that I apply on top of the bisect. A change to the code like this creates the potential for a patch conflict that I then need to manually edit to resolve. If this change was for relatively new code, or better, for a patch that was submitted but not yet merged, then my feelings would be different. I think it would be really useful to have something that scans patches in patchwork. -Geoff