Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp46719pxk; Wed, 30 Sep 2020 17:25:55 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxUDOaul7AKMOc6x81wbfqjhlQOkznnKAKHuhoySpDbcDyOKc50vO0GjjxXKA2ie5q7V2A4 X-Received: by 2002:a17:907:4276:: with SMTP id nq6mr5193249ejb.246.1601511954966; Wed, 30 Sep 2020 17:25:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601511954; cv=none; d=google.com; s=arc-20160816; b=VmzaYCcmYCxpm8kihpMFxVKFP+c+BQM8/qcQJKembz7i4jU/CR9ki+KJ7ji2nbhq9X jMCqyPbXNB+eHFP6xWsMfqJM5Gx0Jzjprs3aDtrRFsNicZqU+WBPznKoKujqxpjLBDP/ 60XxTdNjJo5K04sj9enB25KzO9/vdYFfyo8wYnTJuLHPdOemyzQ2l5sb1MzBXoYRYUIC mLCvwEFLJWvES3hyZsIs5RoRVJdcgb96yFjKYkGz9ZmwCVffKpe0ZWtdeWjapd7DEtQj 3757BaKmp18UTqxKpTQo75GY0MMo/cfs21/aRs8H16et7HQ2iu7jsNecb21Nk0Ap1mBt s5Pw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=e6O73OjsDxvOW+WlmK+Heyu52Yeg2Jcu5CCnSK4DBT0=; b=liGf6ylpZ46EvHnZFg/Lkla07X5WT+ieY51GEbrhxXYAeysM8pzqCmwJ/SrREjTjpz kLVuQIOl0o38zXroHesU6o6Ks6TRuG/gWnUf5Xrp/HqJTEbGBHPzswuFH30PtJ5X4wjy V/T5S/fgcm0BeDXw8x5cT6g0N0ylSFlzcY5jA8ONOh9VIR1f6g+enpagjt3rd6/P6b7y CPCjS/SSBx74ANM4lBYDyvlRIWd/Vlu0YW2ltOBDTNjTXvz+vuexR36/k0GZZzQRlVg+ 45AvPjmpJzkFWAratLNqY05OHYEKZStrMuCHpIVaHSAKMSGhM43NEsKDpZN9xk1cu9MA e3Lw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=dhje9PS0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c11si2253424ejb.541.2020.09.30.17.25.32; Wed, 30 Sep 2020 17:25:54 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=dhje9PS0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730381AbgI3Wcw (ORCPT + 99 others); Wed, 30 Sep 2020 18:32:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51502 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725799AbgI3Wcw (ORCPT ); Wed, 30 Sep 2020 18:32:52 -0400 Received: from mail-ej1-x642.google.com (mail-ej1-x642.google.com [IPv6:2a00:1450:4864:20::642]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0BBE0C0613D0 for ; Wed, 30 Sep 2020 15:32:52 -0700 (PDT) Received: by mail-ej1-x642.google.com with SMTP id q13so5123075ejo.9 for ; Wed, 30 Sep 2020 15:32:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=e6O73OjsDxvOW+WlmK+Heyu52Yeg2Jcu5CCnSK4DBT0=; b=dhje9PS0dPsa5SE9icH+VbXOR2J377+pA6AR6uz7LR2jewZZUPNCxEx6w+qeI+oGkb pgU/Vb4RuH9x1o/7GsN/aY+anl8p5kSPJtUaM9a0o94wriLqJ2cGZs+wE5676T0ulPf8 BXwGd6kMl1uNGRSkEODujQFaabYaR/jyu8XLHnpac3gWWKX1su6fID3NwUeJ94ZoqRVv 1ucqZJMZRb6Oj2TB/uYmuKSarxmrBRQcFAT7o55E1FLn+lf28LlGLiTYQjqrHlvaDdBx eImGrKIKL1bPXTyJB7fx4FhTJ14CiYHzHY+NRMHqOzFuH8/U8OBCntm0+2fpTUpt9kIU gr2g== 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:content-transfer-encoding; bh=e6O73OjsDxvOW+WlmK+Heyu52Yeg2Jcu5CCnSK4DBT0=; b=qFSvzzPeRCaDZkL1yunOVJEC3IlD711y7fBfSvhVTRxuvD+O77j6XyrA6NblGQnbXH vca3ISMN5NWauzDsmqIfo3xb2C1j6BbfMHbcsUxc9sKocHct3rLMakrLlLZd/DTLsYWh Z0oheRRM1H0JLJjvhueikJ6hzF7H6PAK39ZvmbBX5RWe4yfIQeY55loN1WqrGqgIYldP GLkYyuJI3dCnyDFh4n2u1hvN3FC85UY5jH++D7n9NDnndrHAFoSovRmzvby/kvtlLajo 7z+CBdNfQnUdGp93lY3V3u7qzmTVBZYszEhk1iQj6AtiALIGIRSdTwdqDqsW6qbUkgTy S2DQ== X-Gm-Message-State: AOAM533zxh2DFCk1YQX35796mUOzQo7c52fwrBkXkkzX4ggnApPkrjQG szUqL63Z1YEuUdz9jS2B/8qMoysNlivLTU2T8P1fLw== X-Received: by 2002:a17:907:94cf:: with SMTP id dn15mr5256195ejc.114.1601505170533; Wed, 30 Sep 2020 15:32:50 -0700 (PDT) MIME-Version: 1.0 References: <20200930210824.GA12277@embeddedor> <20200930213634.GA12855@embeddedor> In-Reply-To: <20200930213634.GA12855@embeddedor> From: Jann Horn Date: Thu, 1 Oct 2020 00:32:24 +0200 Message-ID: Subject: Re: [PATCH][next] mtd: rawnand: Replace one-element array with flexible-array member To: "Gustavo A. R. Silva" Cc: Stefan Agner , Lucas Stach , Miquel Raynal , Richard Weinberger , Vignesh Raghavendra , Thierry Reding , Jonathan Hunter , linux-mtd@lists.infradead.org, linux-tegra@vger.kernel.org, kernel list , linux-hardening@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 30, 2020 at 11:30 PM Gustavo A. R. Silva wrote: > On Wed, Sep 30, 2020 at 11:10:43PM +0200, Jann Horn wrote: > > On Wed, Sep 30, 2020 at 11:02 PM Gustavo A. R. Silva > > wrote: > > > There is a regular need in the kernel to provide a way to declare hav= ing > > > a dynamically sized set of trailing elements in a structure. Kernel c= ode > > > should always use =E2=80=9Cflexible array members=E2=80=9D[1] for the= se cases. The older > > > style of one-element or zero-length arrays should no longer be used[2= ]. > > > > But this is not such a case, right? Isn't this a true fixed-size > > array? It sounds like you're just changing it because it > > pattern-matched on "array of length 1 at the end of a struct". > > Yeah; I should have changed that 'dynamically' part of the text above > a bit. However, as I commented in the text below, in the case that more > CS IDs are needed (let's wait for the maintainers to comment on this...) > in the future, this change makes the code more maintainable, as for > the allocation part, the developer would only have to update the CS_N > macro to the number of CS IDs that are needed. But in that case, shouldn't you change it to "int cs[CS_N]" and get rid of the struct_size() stuff?