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 */
prev parent 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).