DPDK patches and discussions
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: "Min Hu (Connor)" <humin29@huawei.com>
Cc: <dev@dpdk.org>, <ferruh.yigit@intel.com>,
	<byron.marohn@intel.com>, <yipeng1.wang@intel.com>,
	<ndabilpuram@marvell.com>, <pbhagavatula@marvell.com>
Subject: Re: [dpdk-dev] [PATCH] lib: fix socket id type
Date: Thu, 29 Jun 2023 09:40:38 -0700	[thread overview]
Message-ID: <20230629094038.4a074498@hermes.local> (raw)
In-Reply-To: <1619516192-40499-1-git-send-email-humin29@huawei.com>

On Tue, 27 Apr 2021 17:36:32 +0800
"Min Hu (Connor)" <humin29@huawei.com> wrote:

> From: Chengchang Tang <tangchengchang@huawei.com>
> 
> The variable type of the current socket ID is uint8_t. When traversing all
> nodes, the socket ID is compared with RTE_MAX_NUMA_NODES. Since
> RTE_MAX_NUMA_NODES has not been verified, it may be larger than UCHAR_MAX
> theoretically. This would lead to an infinite loop.
> 
> This patch declares the socket ID type as 'int' or 'unsigned int' by
> referring to the common practice in EAL.
> 
> Fixes: 56b6ef874f80 ("efd: new Elastic Flow Distributor library")
> Fixes: f00708c2aa53 ("node: add IPv4 rewrite and lookup control")
> Cc: stable@dpdk.org
> 
> Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
> Signed-off-by: Min Hu (Connor) <humin29@huawei.com>

An alternative way of handling this would be to add a compile time
check that user did not exceed 255 for numa nodes.

I.e:
diff --git a/lib/efd/rte_efd.c b/lib/efd/rte_efd.c
index dad962ce29bf..8a05909aa4ae 100644
--- a/lib/efd/rte_efd.c
+++ b/lib/efd/rte_efd.c
@@ -505,6 +505,8 @@ rte_efd_create(const char *name, uint32_t max_num_rules, uint32_t key_len,
 	struct rte_ring *r = NULL;
 	unsigned int i;
 
+	RTE_BUILD_BUG_ON(RTE_MAX_NUMA_NODES >= UINT8_MAX);
+
 	efd_list = RTE_TAILQ_CAST(rte_efd_tailq.head, rte_efd_list);
 
 	if (online_cpu_socket_bitmask == 0) {
diff --git a/lib/node/ip4_lookup.c b/lib/node/ip4_lookup.c
index 8bce03d7db9d..0adcd0436b7b 100644
--- a/lib/node/ip4_lookup.c
+++ b/lib/node/ip4_lookup.c
@@ -128,6 +128,8 @@ rte_node_ip4_route_add(uint32_t ip, uint8_t depth, uint16_t next_hop,
 	uint32_t val;
 	int ret;
 
+	RTE_BUILD_BUG_ON(RTE_MAX_NUMA_NODES >= UINT8_MAX);
+
 	in.s_addr = htonl(ip);
 	inet_ntop(AF_INET, &in, abuf, sizeof(abuf));
 	/* Embedded next node id into 24 bit next hop */

      reply	other threads:[~2023-06-29 16:40 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-27  9:36 Min Hu (Connor)
2023-06-29 16:40 ` Stephen Hemminger [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230629094038.4a074498@hermes.local \
    --to=stephen@networkplumber.org \
    --cc=byron.marohn@intel.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=humin29@huawei.com \
    --cc=ndabilpuram@marvell.com \
    --cc=pbhagavatula@marvell.com \
    --cc=yipeng1.wang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).