Message-ID: <f2ba5752-cb22-47a9-0080-d2f978d0f45b@intel.com>
Date:   Tue, 14 Feb 2023 15:19:38 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.7.1
Subject: Re: [Intel-wired-lan] [PATCH] ethernet: ice: avoid gcc-9 integer
 overflow warning
Content-Language: en-US
To:     Arnd Bergmann <arnd@kernel.org>
CC:     Arnd Bergmann <arnd@arndb.de>,
        Jesse Brandeburg <jesse.brandeburg@intel.com>,
        Tony Nguyen <anthony.l.nguyen@intel.com>,
        "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>,
        "Martyna Szapar-Mudlaw" <martyna.szapar-mudlaw@linux.intel.com>,
        <netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
        <intel-wired-lan@lists.osuosl.org>
References: <20230214132002.1498163-1-arnd@kernel.org>
From:   Alexander Lobakin <alexandr.lobakin@intel.com>
In-Reply-To: <20230214132002.1498163-1-arnd@kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ZlFxcElWdGpsOFFQYXNOOHBKR0VVekRyZ1ZJMk9jNkxNWEtGWkVYOE55TldG?=
 =?utf-8?B?UzVIaHJaK0F4MTE5dTR5b1gwUVVMaC8vRVkwbWJCUHV2WTRSNWpIMUtsQWEw?=
 =?utf-8?B?U3plQU9CV1pWNW9LWTg4Y2JjSUZIOXI0R01HcmJ5RThVYzFUK2pDOUNKeW9N?=
 =?utf-8?B?QVU3WTNFS3huUUxmTFQxNmFtQmRZbDlXcUN3ckF0NGd0UUtBTURVeGFUbVVB?=
 =?utf-8?B?QTN5VG5BeVBTaHFEb0Nzbkd0ellUNkxTV0tJeVBYK0h6ajFwandqcHFTenlD?=
 =?utf-8?B?OGw4Sk4yeGpicXJrNURzU0Y3OVI4UlliOXgwNnZHby91MDNoNHZGU0wweTNR?=
 =?utf-8?B?a0MvKzQ4SFd4ZUY5SnBVSTErREw1cDREc3cwQzdKOWhxOTV0S1BFMlFwNEFY?=
 =?utf-8?B?M0k4M3lkbUIvNXFtVVV3cTFtN0Jhdzl2K0tRSDlBeWZmTkFVWDBFanZRajZp?=
 =?utf-8?B?cWdlYktRa0JIQ2FCRGdCYzBKcjdlRWZvSzZEZm5LK3VLYlJyamJMaVhKWUFl?=
 =?utf-8?B?TnFvMkJoUkFVQVRsQ2lQMTZLemZ2MC9FV3VqSnZORUcwc2pGaEZsa0Y0dHoy?=
 =?utf-8?B?Q21UcVpUREF5bHlNcmx1T0hRZFpvdDR4MFBTOFJEVWR3NXZUR0padjVLMVhD?=
 =?utf-8?B?d2pYcktrMmtjYUtyQm9kSEFGNHpEWGZTRVZ1STdDNUFhRUJWb2Nrek51RG5q?=
 =?utf-8?B?aUQ3SEVoeDJjT0hpaitNaTJ4UFhoNGp2Qmh3bTljT3JyTElJYUJ3UitiT1pZ?=
 =?utf-8?B?TE9SbXBYK1lOR2ltL1dqeVJwZnorTHZ6YkVzd01NVDhKTzM2NVVZa3lUMm53?=
 =?utf-8?B?V2x1SDQvK1R6b2phS1BidG15M2xVZHdjVTltMjVBSHV4RUtMcHNCZHcvZnFp?=
 =?utf-8?B?YzAvd2dWWTVSNVkvZEtoVURvaGhPMjJXL29nZ2sxdmxUbHVVSGxjbGU0MHNB?=
 =?utf-8?B?OVVKUittdHZjT1lDdEpEd3FzbTVqYis5SFJadDJicjhMb0tISE9WcUppT2Js?=
 =?utf-8?B?S1B5RDlPNmtRdW9TOUU0TGtZRjZaT1JWUWl4S1BESUY4c3NrS2tMQlk1NERC?=
 =?utf-8?B?WFp0OUhRczVSeHgrV3ZsQ05ZZmdaL0FCM090MkFIMzdxZU5qRnVNMWxSU1U5?=
 =?utf-8?B?QngyaFd0RjRBb0FkNnVWbzNEVHYwbjJBdHlveWpkT0dXY1ZFWnd1cXB6ODli?=
 =?utf-8?B?bncyNnd2THdTSE9Jcm8zdWh5cWVIS0VzQlgxMWo5NVN1MlJCcDRLUm5wQVo5?=
 =?utf-8?B?Vm00UFB6a1lGZ2dJOENZZ0EwRlNBVitmZGhLaHp6a1ZhRUQ2aEJKM2JXb05H?=
 =?utf-8?B?WWY1bEZZaWxvRmlzQU52bjFpaGsrN3RMSFVBeklMbExXUitmLzA2Zkg1U1VP?=
 =?utf-8?B?c2NWYVVxODF2TDhneDBYUHc0bk9DaThCa2Y1U1JQZmRxbGJlVVArMTNqZVZV?=
 =?utf-8?B?dEZQMFNhRzErVW14YTB6LzdwSU94SnZ2aFlhd3J5bzYyV2RXWWxWeHVQQUd2?=
 =?utf-8?B?WW5xV08wMit5OG5wd3oxdGFvTWxyTk90WW1wT0NCSWc5bGV2TVFHNXdNbE16?=
 =?utf-8?B?bTgxb0dham9hcjl6bmJiZFdaWU8yWFpGYmdpUzRtZDlCQlc4OFVtWnlsNGtM?=
 =?utf-8?B?MFhaUXJoeENEcXFrWUdJQlQ3cklYU0NzRzUzWFJZOUs3VENIMjNwRDY2a05X?=
 =?utf-8?B?bWt0TzI1dTZuQldHeU1QR2R3clZhZVlvZllpb2hUS2NtMlF0K052MmNBMm5t?=
 =?utf-8?B?VTVWUkpnZjlnYmRoSG9TL3ErUEtDZG5yTHA5WDhqMDhxTkJ0c1drVkZqZmxX?=
 =?utf-8?B?c3pkMDF0RGxiL1lvS0hFK1lLMG5mSm9kNWp4V3c0S3VXR1J6WDR1bkUrS05o?=
 =?utf-8?B?Z3dtVU9nUmdIQ2IxZEU4WGJINjZhRkd3L29hUkdDUGhXSWVZNW9ab0FWUVl3?=
 =?utf-8?B?cXY4MlMvdlQvYWpiWi9hTzY3TFhHKytTc2F2aEh3NlFtQWJXV0paMVJ1UzBH?=
 =?utf-8?B?bGp3Wk9jWTRKSWU1MjltODNlNzlKeTR5RFNnUEJtRExOTS9UQkEzM2tsQmJD?=
 =?utf-8?B?Lzg0ZjJuU2M2aVAxSFFJam9rdWVnSUw5bUw1dWZvSzZyNnFEY2Z6NUxZaGkx?=
 =?utf-8?B?RStOWUZXaWQxY2dyejFZYmVZTGJxTGlhbTNrYTBsdCtDQU8yL3VJTEpocG1E?=
 =?utf-8?B?Zmc9PQ==?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 314909f6-3f4c-444a-7092-08db0e96ac11
X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB3625.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Feb 2023 14:20:50.0889
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: CiUnYNnVS1sbIiSR8ZYIUF85ktDMDR74txR9U/bARyiUK85Td/dsmtyK/+fWpuT3jVdACNpnxCullbu6Ib6p8uIhCbgXwHONJggJNHmtEUQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR11MB7468
X-OriginatorOrg: intel.com
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

From: Arnd Bergmann <arnd@kernel.org>
Date: Tue, 14 Feb 2023 14:19:49 +0100

> From: Arnd Bergmann <arnd@arndb.de>
> 
> With older compilers like gcc-9, the calculation of the vlan
> priority field causes a warning from the byteswap:
> 
> In file included from drivers/net/ethernet/intel/ice/ice_tc_lib.c:4:
> drivers/net/ethernet/intel/ice/ice_tc_lib.c: In function 'ice_parse_cls_flower':
> include/uapi/linux/swab.h:15:15: error: integer overflow in expression '(int)(short unsigned int)((int)match.key-><U67c8>.<U6698>.vlan_priority << 13) & 57344 & 255' of type 'int' results in '0' [-Werror=overflow]
>    15 |  (((__u16)(x) & (__u16)0x00ffU) << 8) |   \
>       |   ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~
> include/uapi/linux/swab.h:106:2: note: in expansion of macro '___constant_swab16'
>   106 |  ___constant_swab16(x) :   \
>       |  ^~~~~~~~~~~~~~~~~~
> include/uapi/linux/byteorder/little_endian.h:42:43: note: in expansion of macro '__swab16'
>    42 | #define __cpu_to_be16(x) ((__force __be16)__swab16((x)))
>       |                                           ^~~~~~~~
> include/linux/byteorder/generic.h:96:21: note: in expansion of macro '__cpu_to_be16'
>    96 | #define cpu_to_be16 __cpu_to_be16
>       |                     ^~~~~~~~~~~~~
> drivers/net/ethernet/intel/ice/ice_tc_lib.c:1458:5: note: in expansion of macro 'cpu_to_be16'
>  1458 |     cpu_to_be16((match.key->vlan_priority <<
>       |     ^~~~~~~~~~~
> 
> The code looks correct to me, so just avoid the warning by replacing
> the macro expansion with an intermediate variable.
> 
> Fixes: 34800178b302 ("ice: Add support for VLAN priority filters in switchdev")

Should it have "Fixes:" tag if the code itself is correct?

> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  drivers/net/ethernet/intel/ice/ice_tc_lib.c | 10 ++++------
>  1 file changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/net/ethernet/intel/ice/ice_tc_lib.c b/drivers/net/ethernet/intel/ice/ice_tc_lib.c
> index 6b48cbc049c6..e9932446185c 100644
> --- a/drivers/net/ethernet/intel/ice/ice_tc_lib.c
> +++ b/drivers/net/ethernet/intel/ice/ice_tc_lib.c
> @@ -1453,10 +1453,9 @@ ice_parse_cls_flower(struct net_device *filter_dev, struct ice_vsi *vsi,
>  		}
>  
>  		if (match.mask->vlan_priority) {
> +			u16 prio = (match.key->vlan_priority << VLAN_PRIO_SHIFT) & VLAN_PRIO_MASK;

Maybe just u32?

Also, I'd go for FIELD_PREP() here. Even be16_encode_bits(). Or does it
have the same problem on GCC 9?

			__be16 pri;

			pri = be16_encode_bits(match.key->vlan_priority,
					       VLAN_PRIO_MASK);
			headers->vlan_hdr.vlan_prio = pri;

But I suspect you (or somebody else) will say "please don't mix fixes
and improvements" :D Altho I'd go for this one if it silences the warning.

>  			fltr->flags |= ICE_TC_FLWR_FIELD_VLAN_PRIO;
> -			headers->vlan_hdr.vlan_prio =
> -				cpu_to_be16((match.key->vlan_priority <<
> -					     VLAN_PRIO_SHIFT) & VLAN_PRIO_MASK);
> +			headers->vlan_hdr.vlan_prio = cpu_to_be16(prio);
>  		}
>  
>  		if (match.mask->vlan_tpid)
> @@ -1487,10 +1486,9 @@ ice_parse_cls_flower(struct net_device *filter_dev, struct ice_vsi *vsi,
>  		}
>  
>  		if (match.mask->vlan_priority) {
> +			u16 prio = (match.key->vlan_priority << VLAN_PRIO_SHIFT) & VLAN_PRIO_MASK;
>  			fltr->flags |= ICE_TC_FLWR_FIELD_CVLAN_PRIO;
> -			headers->cvlan_hdr.vlan_prio =
> -				cpu_to_be16((match.key->vlan_priority <<
> -					     VLAN_PRIO_SHIFT) & VLAN_PRIO_MASK);
> +			headers->cvlan_hdr.vlan_prio = cpu_to_be16(prio);

^

>  		}
>  	}
> 

Thanks,
Olek