Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp2601955ybf; Mon, 2 Mar 2020 11:59:04 -0800 (PST) X-Google-Smtp-Source: ADFU+vsJumn42XTf+vRJla9AifXXoB6nZwen+PcQDgaXEgg+DUMKW/VGWtkHdbRBy5vGLGB2wlFD X-Received: by 2002:a05:6830:4cd:: with SMTP id s13mr620089otd.181.1583179144596; Mon, 02 Mar 2020 11:59:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583179144; cv=none; d=google.com; s=arc-20160816; b=UUyxGqkOkQrcfOg5LeImb29vFImCDOruHEVZEdFC346PkmlDZUXyRToFvB6y/gdyWy GSkARyluILZ62BUOjw6KXUdSNrbgXYpbrSJv46Qc9vM4+BBzCbXLSBPEvqa4/AKCRmBY jIpL5RSG3lnecRgvtLySWAc1Xx9GWJrNr1cuTpPO5cTU32CjZLw+5Ge5/c1KvZBpjo1U t0cJIEgchZubiBc65zfa9qpWmtncCTNENc4rGhUv51fEagN2ODoGOHEEfUyd5QNXGbgR RgX0FCL1Lf7tSDbr75P4tuwc/qrI2Eh3OH9zRtK3Z84J9U6Pt/MKtsXYRouSwRZHtCA6 QA6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=6uYaEMG8y47FHDBuOPkBLwJJIP6cWUT/0Lq1WvE5eH4=; b=0vwxpUZghtjVA3EaRj+uYvJEbotFbCTg1UMde3C0SiDu5Ua3++bQZHOU22F0GlNEF/ mtGzzftrIb8TBPkGZdDS50WzhTXKeZfn/B66x1K2ppEEpmDvlD92UNmk7lJiOKHIfNBv hMFkNtTRsi+1DW0nKWBySLCRFtcz/ZEOLJbdmoxDAOb0qZd5W5xyXxC//ofyjYHOkmRj yVJTXpVoZ9yCvboMDAeKWI96aGHAaALy3aHjMp6lVqwODDAY43jRaeWgvgRdyUqcAgy/ w12brWvKyFBDuKf/z5LELKH5x49SDZdJcw3dTaLrz72Jb808DIs+drIozbfjAKNBgDZB DEMQ== ARC-Authentication-Results: i=1; mx.google.com; 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 e21si6849933otl.83.2020.03.02.11.58.52; Mon, 02 Mar 2020 11:59:04 -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; 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 S1727201AbgCBT6a (ORCPT + 99 others); Mon, 2 Mar 2020 14:58:30 -0500 Received: from fieldses.org ([173.255.197.46]:35990 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726118AbgCBT6a (ORCPT ); Mon, 2 Mar 2020 14:58:30 -0500 Received: by fieldses.org (Postfix, from userid 2815) id E642C89A; Mon, 2 Mar 2020 14:58:29 -0500 (EST) Date: Mon, 2 Mar 2020 14:58:29 -0500 From: "J. Bruce Fields" To: "Gustavo A. R. Silva" Cc: Trond Myklebust , Anna Schumaker , Chuck Lever , linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH][next] sunrpc: Replace zero-length array with flexible-array member Message-ID: <20200302195829.GD1149@fieldses.org> References: <20200228132323.GA20181@embeddedor> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200228132323.GA20181@embeddedor> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 28, 2020 at 07:23:23AM -0600, Gustavo A. R. Silva wrote: > The current codebase makes use of the zero-length array language > extension to the C90 standard, but the preferred mechanism to declare > variable-length types such as these ones is a flexible array member[1][2], > introduced in C99: > > struct foo { > int stuff; > struct boo array[]; > }; > > By making use of the mechanism above, we will get a compiler warning > in case the flexible array does not occur last in the structure, which > will help us prevent some kind of undefined behavior bugs from being > inadvertently introduced[3] to the codebase from now on. > > Also, notice that, dynamic memory allocations won't be affected by > this change: > > "Flexible array members have incomplete type, and so the sizeof operator > may not be applied. As a quirk of the original implementation of > zero-length arrays, sizeof evaluates to zero."[1] I don't understand the quoted sentences at all. But I assume you're telling me that sizeof(struct svc_deferred_req) won't be changed by this patch, so, good, applied. Thanks! --b. > > This issue was found with the help of Coccinelle. > > [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html > [2] https://github.com/KSPP/linux/issues/21 > [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") > > Signed-off-by: Gustavo A. R. Silva > --- > include/linux/sunrpc/svc.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/linux/sunrpc/svc.h b/include/linux/sunrpc/svc.h > index 1afe38eb33f7..7f0a83451bc0 100644 > --- a/include/linux/sunrpc/svc.h > +++ b/include/linux/sunrpc/svc.h > @@ -380,7 +380,7 @@ struct svc_deferred_req { > struct cache_deferred_req handle; > size_t xprt_hlen; > int argslen; > - __be32 args[0]; > + __be32 args[]; > }; > > struct svc_process_info { > -- > 2.25.0