From: Bruce Richardson <bruce.richardson@intel.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: <dev@dpdk.org>, <stable@dpdk.org>
Subject: Re: [RFC v2 02/14] test: avoid long hash names
Date: Fri, 5 Dec 2025 08:29:39 +0000 [thread overview]
Message-ID: <aTKX8x0W3mU6BsC-@bricha3-mobl1.ger.corp.intel.com> (raw)
In-Reply-To: <20251205022948.327743-3-stephen@networkplumber.org>
On Thu, Dec 04, 2025 at 06:28:11PM -0800, Stephen Hemminger wrote:
> The test was using hash table names which were too long and
> would break if the hash library was checking the parameters.
>
> Fixes: af75078fece3 ("first public release")
> Fixes: 9c7d8eed1a45 ("test/hash: add RCU tests")
> Fixes: 567bb951716f ("hash: reclaim RCU defer queue")
> Cc: stable@dpdk.org
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> ---
> app/test/test_hash.c | 29 +++++++++++++++++++----------
> 1 file changed, 19 insertions(+), 10 deletions(-)
>
> diff --git a/app/test/test_hash.c b/app/test/test_hash.c
> index 5791fd7f4c..8cecc28d11 100644
> --- a/app/test/test_hash.c
> +++ b/app/test/test_hash.c
> @@ -1399,8 +1399,16 @@ static int test_hash_creation_with_bad_parameters(void)
> return -1;
> }
>
> - memcpy(¶ms, &ut_params, sizeof(params));
> - params.name = "creation_with_bad_parameters_0";
> + params = ut_params;
> + params.name = "really_long_name_of_22";
> + handle = rte_hash_create(¶ms);
> + if (handle != NULL) {
> + rte_hash_free(handle);
> + printf("Impossible creating hash successfully with excessively long name\n");
> + return -1;
> + }
> +
I'm not sure about this behaviour, for something like the hash name. I'd
tend more towards having the hash library just truncate the name rather
than returning an error if it was too long.
Also, I worry that this could break end-applications which were relying on
previous behaviour of ignoring long names.
What do you/others think?
/Bruce
next prev parent reply other threads:[~2025-12-05 8:29 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-02 17:24 [RFC 0/8] first steps in fixing buffer overflow Stephen Hemminger
2025-12-02 17:24 ` [RFC 1/8] eal: use C library to parse filesystem table Stephen Hemminger
2025-12-02 17:24 ` [RFC 2/8] hash: fix possible ring name overflow Stephen Hemminger
2025-12-02 17:24 ` [RFC 3/8] eal: warn if thread name is truncated Stephen Hemminger
2025-12-02 17:24 ` [RFC 4/8] eal: avoid format overflow when handling addresses Stephen Hemminger
2025-12-02 17:24 ` [RFC 5/8] ethdev: avoid possible overflow in xstat names Stephen Hemminger
2025-12-02 17:24 ` [RFC 6/8] efd: avoid overflowing ring name Stephen Hemminger
2025-12-02 17:24 ` [RFC 7/8] eal: add check for sysfs path overflow Stephen Hemminger
2025-12-02 17:24 ` [RFC 8/8] eal: limit maximum runtime directory and socket paths Stephen Hemminger
2025-12-05 2:28 ` [RFC v2 00/14] lib: check for string overflow Stephen Hemminger
2025-12-05 2:28 ` [RFC v2 01/14] eal: use C library to parse filesystem table Stephen Hemminger
2025-12-05 2:28 ` [RFC v2 02/14] test: avoid long hash names Stephen Hemminger
2025-12-05 8:29 ` Bruce Richardson [this message]
2025-12-05 2:28 ` [RFC v2 03/14] lpm: restrict name size Stephen Hemminger
2025-12-05 2:28 ` [RFC v2 04/14] hash: avoid possible ring name overflow Stephen Hemminger
2025-12-05 2:28 ` [RFC v2 05/14] graph: avoid overflowing comment buffer Stephen Hemminger
2025-12-05 2:28 ` [RFC v2 06/14] eal: warn if thread name is truncated Stephen Hemminger
2025-12-05 8:32 ` Bruce Richardson
2025-12-05 2:28 ` [RFC v2 07/14] eal: avoid format overflow when handling addresses Stephen Hemminger
2025-12-05 2:28 ` [RFC v2 08/14] ethdev: avoid possible overflow in xstat names Stephen Hemminger
2025-12-05 8:34 ` Bruce Richardson
2025-12-05 2:28 ` [RFC v2 09/14] vhost: check for overflow in xstat name Stephen Hemminger
2025-12-05 2:28 ` [RFC v2 10/14] efd: avoid overflowing ring name Stephen Hemminger
2025-12-05 8:37 ` Bruce Richardson
2025-12-05 2:28 ` [RFC v2 11/14] eal: add check for sysfs path overflow Stephen Hemminger
2025-12-05 2:28 ` [RFC v2 12/14] eal: limit maximum runtime directory and socket paths Stephen Hemminger
2025-12-05 8:46 ` Bruce Richardson
2025-12-05 2:28 ` [RFC v2 13/14] eal: check for hugefile path overflow Stephen Hemminger
2025-12-05 2:28 ` [RFC v2 14/14] lib: enable format overflow warnings Stephen Hemminger
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=aTKX8x0W3mU6BsC-@bricha3-mobl1.ger.corp.intel.com \
--to=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=stable@dpdk.org \
--cc=stephen@networkplumber.org \
/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).