Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp3293411pxf; Sun, 28 Mar 2021 20:25:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzwYDEARLoDIDgehqFtIJMuoJ5Vey4yefhf2qI/Aa0+37yX0ctKDCeXNBzQUwKxWbzMlbat X-Received: by 2002:a05:6402:382:: with SMTP id o2mr27319486edv.238.1616988324587; Sun, 28 Mar 2021 20:25:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1616988324; cv=none; d=google.com; s=arc-20160816; b=UXadND8TAnrWK1mpvBsUSmpy00h1Rc3VLZL6aO1XT6EXrMvmAgnhvOBZLhop3MHbx9 QsyA1i+SDfKtzbLIvhmLflpy57oOSkWjVAx+s7Y8GgffduL+RTxsbUz4N24jErlOEVDg +SrYkYV7ur/eW2xOyWILE4zLcfW+vEryI/Kn+YXDyhDzqlN4QoxLFnF6HgITtMcaxH+a zeV3oxBhW3CdmUpJ0kgTgw5r4hamUAS0q/G5ZZVYVFpwkA1rwIDP1ITLKv6WTLlZUN8H nbs3HHWnDjPpOiQSAiSlRjDFJJNANtbQUDmDm9p9asSk03VNvP/gQ76neN1vLLgsATn/ CAjA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-language:content-transfer-encoding :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:ironport-sdr:ironport-sdr; bh=q8wJ4511doeHsCbJ3hy895wqeeMIrJ2qQKHfZq27zpI=; b=yGsqXf7Ig51AaA+UXTI8Vt9iyQ/jZ4+CLLDyq/IuzlENy+iRql8WbX4dqoSjEvVFnY rrUkBf/Cv+H3jB6Rc0jFNJuT1F1HfOzm6V892vIdblfFw9I0+JnQvgx306YAcdc7mJKU Yf/If7PP+kOABGCZ67ASOftjVGHCVFDuKAE6lDnD9n1++yHueQ6ecznkSbzOTRMU9u1M oz5T9bDF6oPM8OXjRu0zaJLL0kUhn11m/7iumeYmvnU/lctpD/QYNz1LQsz132I7nFU+ QMVcMBNNvpgqSvR1ljMdMMhO+HDAwAd6N57EB+0gRxK5lPuhPRTiywV9mRmG/LjNsD5L T3JA== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u27si12041430ejj.726.2021.03.28.20.24.51; Sun, 28 Mar 2021 20:25:24 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230271AbhC2DT3 (ORCPT + 99 others); Sun, 28 Mar 2021 23:19:29 -0400 Received: from mga14.intel.com ([192.55.52.115]:7351 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230209AbhC2DTV (ORCPT ); Sun, 28 Mar 2021 23:19:21 -0400 IronPort-SDR: NLUK0cWTVzWOM7rJYg/DEASXDOZpIh21uEbu+3VfWr0pnb3rkI+fkJTj7daNvql/2KTgI75VtN GBzvnhOGU9fQ== X-IronPort-AV: E=McAfee;i="6000,8403,9937"; a="190931290" X-IronPort-AV: E=Sophos;i="5.81,285,1610438400"; d="scan'208";a="190931290" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Mar 2021 20:19:21 -0700 IronPort-SDR: ARP9HMJ6j3HLkrVp+cGiWP6izK7yof5wX5K0LHOiCR7NEU0PCCBuWu+pMar0EDarsu8Qg1Yuk9 9tTEsQ3oiCZg== X-IronPort-AV: E=Sophos;i="5.81,285,1610438400"; d="scan'208";a="526786945" Received: from samudral-mobl.amr.corp.intel.com (HELO [10.212.80.176]) ([10.212.80.176]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Mar 2021 20:19:20 -0700 Subject: Re: [PATCH net 1/4] virtchnl: Fix layout of RSS structures To: Geert Uytterhoeven Cc: anthony.l.nguyen@intel.com, Norbert Ciosek , "David S. Miller" , Jakub Kicinski , netdev , sassmann@redhat.com, Konrad Jankowski , Mateusz Palczewski , Linux Kernel Mailing List References: <20210325223119.3991796-1-anthony.l.nguyen@intel.com> <20210325223119.3991796-2-anthony.l.nguyen@intel.com> From: "Samudrala, Sridhar" Message-ID: Date: Sun, 28 Mar 2021 20:19:19 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 3/27/2021 2:53 AM, Geert Uytterhoeven wrote: > Hi Samudrala, > > On Fri, Mar 26, 2021 at 11:45 PM Samudrala, Sridhar > wrote: >> On 3/26/2021 1:06 AM, Geert Uytterhoeven wrote: >>> On Thu, Mar 25, 2021 at 11:29 PM Tony Nguyen wrote: >>> From: Norbert Ciosek >>> >>> Remove padding from RSS structures. Previous layout >>> could lead to unwanted compiler optimizations >>> in loops when iterating over key and lut arrays. >>> >>> From an earlier private conversation with Mateusz, I understand the real >>> explanation is that key[] and lut[] must be at the end of the >>> structures, because they are used as flexible array members? >>> >>> Fixes: 65ece6de0114 ("virtchnl: Add missing explicit padding to structures") >>> Signed-off-by: Norbert Ciosek >>> Tested-by: Konrad Jankowski >>> Signed-off-by: Tony Nguyen >>> >>> --- a/include/linux/avf/virtchnl.h >>> +++ b/include/linux/avf/virtchnl.h >>> @@ -476,7 +476,6 @@ struct virtchnl_rss_key { >>> u16 vsi_id; >>> u16 key_len; >>> u8 key[1]; /* RSS hash key, packed bytes */ >>> - u8 pad[1]; >>> }; >>> >>> VIRTCHNL_CHECK_STRUCT_LEN(6, virtchnl_rss_key); >>> @@ -485,7 +484,6 @@ struct virtchnl_rss_lut { >>> u16 vsi_id; >>> u16 lut_entries; >>> u8 lut[1]; /* RSS lookup table */ >>> - u8 pad[1]; >>> }; >>> >>> If you use a flexible array member, it should be declared without a size, >>> i.e. >>> >>> u8 key[]; >>> >>> Everything else is (trying to) fool the compiler, and leading to undefined >>> behavior, and people (re)adding explicit padding. >> This header file is shared across other OSes that use C++ that doesn't support >> flexible arrays. So the structures in this file use an array of size 1 as a last >> element to enable variable sized arrays. > I don't think it is accepted practice to have non-Linux-isms in > include/*linux*/avf/virtchnl.h header files. Moreover, using a size > of 1 is counter-intuitive for people used to Linux kernel development, > and may lead to off-by-one errors in calculation of sizes. > > If you insist on ignoring the above, this definitely deserves a > comment next to the member's declaration. Sure. We can add a comment indicating that these fields are used variable sized arrays. Thanks Sridhar