From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id CB9D1A0548; Tue, 27 Apr 2021 12:45:42 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id AFC9540142; Tue, 27 Apr 2021 12:45:42 +0200 (CEST) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by mails.dpdk.org (Postfix) with ESMTP id 488F04003D for ; Tue, 27 Apr 2021 12:45:41 +0200 (CEST) IronPort-SDR: qjjkNMzAg1xunG4C0c4v9EgQ8nO3qy3CJEO2uYqZ8InZJcJmOyvmNspIccs8AebkhYkrHMcql8 3jNYQlhwMpOg== X-IronPort-AV: E=McAfee;i="6200,9189,9966"; a="257789436" X-IronPort-AV: E=Sophos;i="5.82,254,1613462400"; d="scan'208";a="257789436" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Apr 2021 03:45:40 -0700 IronPort-SDR: TqRYN0NavfMtCPG/JJQOkUHk0ZeWGGpZLogDF1sSkbvtoHOWIyhF1XQbxg5R1eLFvw4hP24N4N wgJURzIpgFWQ== X-IronPort-AV: E=Sophos;i="5.82,254,1613462400"; d="scan'208";a="457590888" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.221.231]) ([10.213.221.231]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Apr 2021 03:45:38 -0700 To: Chengchang Tang , "Min Hu (Connor)" , dev@dpdk.org References: <1619075569-33619-1-git-send-email-humin29@huawei.com> <5871c7f5-58d7-e101-c544-f5374936f09c@huawei.com> From: Ferruh Yigit X-User: ferruhy Message-ID: <874f0364-0376-e006-a185-150aec7101f8@intel.com> Date: Tue, 27 Apr 2021 11:45:35 +0100 MIME-Version: 1.0 In-Reply-To: <5871c7f5-58d7-e101-c544-f5374936f09c@huawei.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH] net/bonding: fix socket id check X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 4/27/2021 3:44 AM, Chengchang Tang wrote: > > > On 2021/4/26 22:54, Ferruh Yigit wrote: >> On 4/22/2021 8:12 AM, Min Hu (Connor) wrote: >>> From: Chengchang Tang >>> >>> The socket ID entered by user is cast to an unsigned integer. However, >>> the value may be an illegal negative value, which may cause some >>> problems. In this case, an error should be returned. >>> >> >> +1 to fix >> >>> In addition, the socket ID may be an invalid positive number, which is >>> also processed in this patch. >>> >>> Fixes: 2efb58cbab6e ("bond: new link bonding library") >>> Cc: stable@dpdk.org >>> >>> Signed-off-by: Chengchang Tang >>> Signed-off-by: Min Hu (Connor) >>> --- >>> drivers/net/bonding/rte_eth_bond_args.c | 4 ++-- >>> 1 file changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/drivers/net/bonding/rte_eth_bond_args.c b/drivers/net/bonding/rte_eth_bond_args.c >>> index 8c5f90d..bcc0fe3 100644 >>> --- a/drivers/net/bonding/rte_eth_bond_args.c >>> +++ b/drivers/net/bonding/rte_eth_bond_args.c >>> @@ -207,12 +207,12 @@ bond_ethdev_parse_socket_id_kvarg(const char *key __rte_unused, >>> return -1; >>> >>> errno = 0; >>> - socket_id = (uint8_t)strtol(value, &endptr, 10); >>> + socket_id = strtol(value, &endptr, 10); >> >> 'strtol()' returns 'long int', but implicitly casting it to 'int'. My concern is >> if this cause a static analysis tool warning. >> What do you think to have 'socket_id' type as 'long int'? >> > I think it would be better to cast to the 'int' here, for reasons below. > Independent from below reasons, converting from user provided "long int" to 'int' will cause losing value and may lead wrong checks, Like if user provided '-4294967281' (0xffffffff0000000f), when you cast to 'int', it will become '15' (0xf) and will pass from validation checks. So I think better to verify the value first as "long int", later cast it to 'int'. >>> if (*endptr != 0 || errno != 0) >>> return -1; >>> >>> /* validate socket id value */ >>> - if (socket_id >= 0) { >>> + if (socket_id >= 0 && socket_id < RTE_MAX_NUMA_NODES) {> *(uint8_t *)extra_args = (uint8_t)socket_id; >> >> Here there is an assumption that RTE_MAX_NUMA_NODES will be less than >> 'UCHAR_MAX', perhaps it can be good to add a check to verify this assumption. > > Currently, it is unlikely that RTE_MAX_NUMA_NODES will be greater than 256. Therefore, > adding such check will not cause any problems. But I don't think it's necessary to put > such restrictions on it (i.e. RTE_MAX_NUMA_NODES should be less than UCHAR_MAX). Restriction comes from provided 'extra_args' being 'uint8_t', I just suggest checking this. > I checked all references to RTE_MAX_NUMA_NODES, and usually socket_id is of type 'int' > or 'unsigned int' (Only the efd, node, and bonding specify 'unsigned char' for socket > IDs.). And for that, I think it will be better to change the socket id type to 'int' > in this patch. For the type of socket id in efd and node, I will send new patches to > modify it. >> >>> return 0; >>> } >>> >> >> >> . >> >