Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp3588944ybe; Sun, 15 Sep 2019 19:32:49 -0700 (PDT) X-Google-Smtp-Source: APXvYqz91jMWlN3H0qH+jikd5JiO1b9zZyOAtH7uM7t1RYPLluwAigGLKwFBuM8ttPJCpMkAlvVz X-Received: by 2002:a50:8a9a:: with SMTP id j26mr59820315edj.251.1568601169498; Sun, 15 Sep 2019 19:32:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568601169; cv=none; d=google.com; s=arc-20160816; b=XKjrelpfyCT9YXl3lrhgymSE43RlGgKcS0O93VFKYRy1ygcbVLq5c1Mlr2WCJV1mOt UswobhioPjVdH7Zg0oXfdlpjoIlACueGstZXgk5a0/42LoNjptCP61S6qAK3/DpgMANT QATy8S3DYsHScacJHWTAInkZIZrExGxtMCpiJKWUF4Rof0TcuPm+SfDKu16aAYyGQEwX hREu9zdB21ob93AfnOFysP0523bXQFLqRRD5+8dNZWjhc93++mxtMtkaVPEeu3mhcM5p qHa4Ywb3xbPQjaEMQJx61dAlLFF+OmJ7YvVwmvh4lrYx5WbobFLyC06QqTwhswekdjOX JFMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=asP2MeWC9oWpx/gaOK+HIONcvfsMWrL7pF7piAoOX20=; b=ldkUGf19PE+cNmniMrsxaHhu6Fxad+35tMKgi4oeyYLijQfcosdAFddCUghq0JJmZi 1weI+1LLbgnVaqy3790I9ae3DezCC286bPgNAhhWryCtKDaHCc3yTzJQyiF5wQoRQzOs 5bo9Cn/AC3bOPOvt0aivvaGTrtPmncv4IvU/xmC7ANImtBeg2SYB5A6aJnpWSKg7xem5 n2T4usaDVisbkCoY2wB9iFp7d9IzX6vWfQX/KyLpPwIHRciGFWEopebJJZ7prlYHsTnH ueJetlL3RcXHe+SPakd4P8YpY2yGDWfrq9X/1mbzSPABR6lgEMI6g4q2mZ3Rp1elkcZj 0ZXA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=S1VB0FI7; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o11si8289602ejj.127.2019.09.15.19.32.25; Sun, 15 Sep 2019 19:32:49 -0700 (PDT) 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=pass header.i=@gmail.com header.s=20161025 header.b=S1VB0FI7; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726898AbfIOV6l (ORCPT + 99 others); Sun, 15 Sep 2019 17:58:41 -0400 Received: from mail-wm1-f68.google.com ([209.85.128.68]:53886 "EHLO mail-wm1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726786AbfIOV6l (ORCPT ); Sun, 15 Sep 2019 17:58:41 -0400 Received: by mail-wm1-f68.google.com with SMTP id i16so2022812wmd.3 for ; Sun, 15 Sep 2019 14:58:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=asP2MeWC9oWpx/gaOK+HIONcvfsMWrL7pF7piAoOX20=; b=S1VB0FI71TIhbEAW+HnuYeu8lYF8IPAD5FbR8FKruD2QVdqxM5xYfHY82UeYuYHI38 64nKSioCUrLEnubE0nEDImhDcGu1KxkcPyXvp2fQTSLRX6PqBfiSLWjroWJ0V2LZQ2hO eAQ4HbdEBCwaVhQt62GLJLi5lXY0Ok9tQm6EmRi1VluYcF6AujQFN8e9yz/57qpOqxp6 9VhH0IskrMZgdi2BA7Sy8uhe1IzWkJRzYK+CgDyPlzzhzdrOcy/lLnMOPC6DtBCw4Vo8 vyaH+FP4qqe1U+ckkQW+aD3UkKy5N5p1sdrOwwVaGE6JVghnT/jz7B37T5nhQzIF2W52 P80w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=asP2MeWC9oWpx/gaOK+HIONcvfsMWrL7pF7piAoOX20=; b=rMjLYDhRjaTFZrLkBWKSlOU0V07CylRCCWAOWahyvL7Nw2Sevppa+35KQMTFkc296e 6V7MDfq25zFG75TWRhSSYC+amhjpEJKQ1xToFJm19PzJYF1OAF7iG+cx7S/tdN93NIWi 3LDfb74ZzikF56KcteRU647LWZJjRRfAePieUCN9xz6CXwcv1jnLWQQaYcT4aaxEBRNw LOFAqXkhvgqlOUIZ6bwroRovloUAvF2ZRfBt1AeeZVp0nfIbCz3smtF/BUXOwy3UUWUt CPK7o03ALarKq6i4hu+BPehSKwThEJKgB0axYLYkF4H6HlcIeXW73Q7+vy0WUcd/265c 7OeA== X-Gm-Message-State: APjAAAUH3IReYTrkNlAfs6AfaM6P5SXwtmanQiGlhrD2qEUlraSEy87C Rb/pmWoeXjbdN/oNJwCAxD4H7yPCL2DAZPcjw6o= X-Received: by 2002:a1c:eb16:: with SMTP id j22mr6071758wmh.176.1568584719359; Sun, 15 Sep 2019 14:58:39 -0700 (PDT) MIME-Version: 1.0 References: <20190829005009.GA5895@embeddedor> In-Reply-To: <20190829005009.GA5895@embeddedor> From: Richard Weinberger Date: Sun, 15 Sep 2019 23:58:28 +0200 Message-ID: Subject: Re: [PATCH] ubifs: super: Use struct_size() helper To: "Gustavo A. R. Silva" Cc: Richard Weinberger , Artem Bityutskiy , Adrian Hunter , linux-mtd@lists.infradead.org, LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 29, 2019 at 2:50 AM 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 ubifs_znode { > ... > struct ubifs_zbranch zbranch[]; > }; > > Make use of the struct_size() helper instead of an open-coded version > in order to avoid any potential type mistakes. > > So, replace the following form: > > sizeof(struct ubifs_znode) + c->fanout * sizeof(struct ubifs_zbranch) > > with: > > struct_size(c->cnext, zbranch, c->fanout) > > This code was detected with the help of Coccinelle. > > Signed-off-by: Gustavo A. R. Silva > --- > fs/ubifs/super.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c > index 2706f13e3eb9..ca86489048c8 100644 > --- a/fs/ubifs/super.c > +++ b/fs/ubifs/super.c > @@ -661,8 +661,7 @@ static int init_constants_sb(struct ubifs_info *c) > long long tmp64; > > c->main_bytes = (long long)c->main_lebs * c->leb_size; > - c->max_znode_sz = sizeof(struct ubifs_znode) + > - c->fanout * sizeof(struct ubifs_zbranch); > + c->max_znode_sz = struct_size(c->cnext, zbranch, c->fanout); First of all, c->fanout is bound checked. I had to lookup how struct_size() works to understand this single line of code and why you use the completely unrelated c->cnext here. Sorry this change does not make the code any better just harder to read. -- Thanks, //richard