automatic DPDK test reports
 help / color / mirror / Atom feed
From: 0-day Robot <robot@bytheb.org>
To: test-report@dpdk.org, Stephen Hemminger <stephen@networkplumber.org>
Subject: |SUCCESS| pw159214 [PATCH v5 03/17] hash: add checks for hash name length
Date: Tue, 16 Dec 2025 11:12:02 -0500	[thread overview]
Message-ID: <20251216161202.762473-1-robot@bytheb.org> (raw)
In-Reply-To: <20251207191242.165619-4-stephen@networkplumber.org>

Test-Label: 0day Robot - Claude SONNET
Test-Status: SUCCESS
http://dpdk.org/patch/159214

_AI Review Comments Available_

git sha: [Could not determine from patch content]
Author: Stephen Hemminger <stephen@networkplumber.org>
Subject: [PATCH v5 03/17] hash: add checks for hash name length

This commit adds name length validation to hash creation functions and 
improves error handling for ring creation failures. It also adds tests 
for the new validation logic.

> diff --git a/app/test/test_hash.c b/app/test/test_hash.c
> index 5791fd7f4c..0b608a3d74 100644
> --- a/app/test/test_hash.c
> +++ b/app/test/test_hash.c
> @@ -1120,6 +1120,14 @@ fbk_hash_unit_test(void)
>  		.socket_id = RTE_MAX_NUMA_NODES + 1, /* invalid socket */
>  	};
>  
> +	/* try and create hash with an excessively long name */
> +	struct rte_fbk_hash_params invalid_params_long_name = {
> +		.name = "four_byte_key_hash_name_length_32",
> +		.entries = 4,
> +		.entries_per_bucket = 2,
> +		.socket_id = 0,
> +	};
> +

Is this test name actually long enough to trigger the validation? The
test name appears to be exactly 32 characters but the test should verify
it exceeds RTE_FBK_HASH_NAMESIZE.

[ ... ]

> diff --git a/lib/hash/rte_cuckoo_hash.c b/lib/hash/rte_cuckoo_hash.c
> index 2c92c51624..f9c4a0e302 100644
> --- a/lib/hash/rte_cuckoo_hash.c
> +++ b/lib/hash/rte_cuckoo_hash.c
> @@ -278,12 +278,16 @@ rte_hash_create(const struct rte_hash_parameters *params)
>  	else
>  		num_key_slots = params->entries + 1;
>  
> -	snprintf(ring_name, sizeof(ring_name), "HT_%s", params->name);
> +	/* Ring name may get truncated, conflict detected on ring creation */
> +	if (snprintf(ring_name, sizeof(ring_name), "HT_%s", params->name)
> +	    >= (int)sizeof(ring_name))
> +		HASH_LOG(NOTICE, "ring name truncated to '%s'", ring_name);
> +

Can this truncation check be reached given the earlier name length
validation in rte_hash_create()? The validation should prevent names
that would cause truncation when prefixed with "HT_".

> @@ -1621,8 +1639,9 @@ rte_hash_rcu_qsbr_add(struct rte_hash *h, struct rte_hash_rcu_config *cfg)
>  		h->dq = rte_rcu_qsbr_dq_create(&params);
>  		if (h->dq == NULL) {
>  			rte_free(hash_rcu_cfg);
> -			HASH_LOG(ERR, "HASH defer queue creation failed");
> +			HASH_LOG(ERR, "HASH defer queue creation failed: %s",
> +				 rte_strerror(rte_errno));

Does rte_rcu_qsbr_dq_create() guarantee that rte_errno is set on failure?
Without this guarantee, the error message might be misleading.

> diff --git a/lib/hash/rte_fbk_hash.c b/lib/hash/rte_fbk_hash.c
> index 38b15a14d1..2304db7551 100644
> --- a/lib/hash/rte_fbk_hash.c
> +++ b/lib/hash/rte_fbk_hash.c
> @@ -83,7 +83,7 @@ rte_fbk_hash_create(const struct rte_fbk_hash_params *params)
>  {
>  	struct rte_fbk_hash_table *ht = NULL;
>  	struct rte_tailq_entry *te;
> -	char hash_name[RTE_FBK_HASH_NAMESIZE];
> +	char *hash_name = NULL;
>  	const uint32_t mem_size =
>  			sizeof(*ht) + (sizeof(ht->t[0]) * params->entries);
>  	uint32_t i;
> @@ -105,7 +107,14 @@ rte_fbk_hash_create(const struct rte_fbk_hash_params *params)
>  		return NULL;
>  	}
>  
> -	snprintf(hash_name, sizeof(hash_name), "FBK_%s", params->name);
> +	if (strlen(params->name) >= RTE_FBK_HASH_NAMESIZE) {
> +		rte_errno = ENAMETOOLONG;
> +		return NULL;
> +	}
> +
> +	/* don't care if hash_name is NULL */
> +	int unused __rte_unused;
> +	unused = asprintf(&hash_name, "FBK_%s", params->name);

Does this code handle asprintf() failure correctly? If asprintf() fails
and returns -1 with hash_name set to NULL, the subsequent code using
hash_name could crash or behave incorrectly.

> @@ -170,6 +179,7 @@ rte_fbk_hash_create(const struct rte_fbk_hash_params *params)
>  
>  exit:
>  	rte_mcfg_tailq_write_unlock();
> +	free(hash_name);

Does this code have a memory leak on the success path? The hash_name is
allocated with asprintf() but only freed at the exit label, which
appears to be used for both success and failure cases.

  parent reply	other threads:[~2025-12-16 16:12 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20251205022948.327743-1-stephen@networkplumber.org>
     [not found] ` <20251207191242.165619-1-stephen@networkplumber.org>
     [not found]   ` <20251207191242.165619-15-stephen@networkplumber.org>
2025-12-07 19:13     ` |SUCCESS| pw159225 [PATCH v5 14/17] eal: handle long shared library path checkpatch
2025-12-16 16:12     ` 0-day Robot
     [not found]   ` <20251207191242.165619-11-stephen@networkplumber.org>
2025-12-07 19:16     ` |SUCCESS| pw159221 [PATCH v5 10/17] eal: add check for sysfs path overflow checkpatch
2025-12-16 16:12     ` |SUCCESS| pw159221 " 0-day Robot
     [not found]   ` <20251207191242.165619-10-stephen@networkplumber.org>
2025-12-07 19:16     ` |SUCCESS| pw159220 [PATCH v5 09/17] eal: avoid format overflow when handling addresses checkpatch
2025-12-16 16:12     ` 0-day Robot
     [not found]   ` <20251207191242.165619-9-stephen@networkplumber.org>
2025-12-07 19:16     ` |SUCCESS| pw159219 [PATCH v5 08/17] eal: warn if thread name is truncated checkpatch
2025-12-16 16:12     ` |SUCCESS| pw169219 " 0-day Robot
     [not found]   ` <20251207191242.165619-6-stephen@networkplumber.org>
2025-12-07 19:17     ` |SUCCESS| pw159216 [PATCH v5 05/17] latencystats: add check for string overflow checkpatch
2025-12-16 16:12     ` 0-day Robot
     [not found]   ` <20251207191242.165619-5-stephen@networkplumber.org>
2025-12-07 19:17     ` |SUCCESS| pw159215 [PATCH v5 04/17] graph: avoid overflowing comment buffer checkpatch
2025-12-16 16:12     ` 0-day Robot
     [not found]   ` <20251207191242.165619-2-stephen@networkplumber.org>
2025-12-07 19:17     ` |SUCCESS| pw159212 [PATCH v5 01/17] eal: use C library to parse filesystem table checkpatch
2025-12-16 16:11     ` 0-day Robot
     [not found]   ` <20251207191242.165619-18-stephen@networkplumber.org>
2025-12-07 18:47     ` |SUCCESS| pw159212-159228 [PATCH v5 17/17] lib: enable format overflow warnings qemudev
2025-12-07 18:54     ` |FAILURE| " qemudev
2025-12-07 19:19     ` |SUCCESS| pw159228 " checkpatch
2025-12-07 20:59     ` |FAILURE| " 0-day Robot
2025-12-08 10:39     ` |FAILURE| pw159212-159228 [PATCH] [v5,17/17] lib: enable format over dpdklab
2025-12-08 10:43     ` dpdklab
2025-12-08 10:44     ` |WARNING| " dpdklab
2025-12-08 10:45     ` |PENDING| " dpdklab
2025-12-08 10:45     ` |SUCCESS| " dpdklab
2025-12-08 10:45     ` |FAILURE| " dpdklab
2025-12-08 10:47     ` dpdklab
2025-12-08 10:47     ` |SUCCESS| " dpdklab
2025-12-08 10:48     ` |FAILURE| " dpdklab
2025-12-08 10:51     ` |WARNING| " dpdklab
2025-12-08 11:02     ` |SUCCESS| " dpdklab
2025-12-08 11:02     ` |FAILURE| " dpdklab
2025-12-08 11:03     ` |SUCCESS| " dpdklab
2025-12-08 11:12     ` dpdklab
2025-12-08 11:12     ` |FAILURE| " dpdklab
2025-12-08 11:15     ` dpdklab
2025-12-08 11:22     ` |WARNING| " dpdklab
2025-12-08 11:24     ` |FAILURE| " dpdklab
2025-12-08 14:29     ` dpdklab
2025-12-08 16:06     ` dpdklab
2025-12-10  4:01     ` dpdklab
2025-12-10  4:17     ` dpdklab
2025-12-16  1:28     ` dpdklab
2025-12-16 16:12     ` |SUCCESS| pw159228 [PATCH v5 17/17] lib: enable format overflow warnings 0-day Robot
2025-12-16 23:31     ` |SUCCESS| pw159212-159228 [PATCH] [v5,17/17] lib: enable format over dpdklab
2025-12-16 23:38     ` |WARNING| " dpdklab
2025-12-16 23:39     ` |SUCCESS| " dpdklab
2025-12-16 23:43     ` |FAILURE| " dpdklab
2025-12-16 23:49     ` |SUCCESS| " dpdklab
2025-12-16 23:59     ` |FAILURE| " dpdklab
2025-12-17  0:09     ` |WARNING| " dpdklab
     [not found]   ` <20251207191242.165619-17-stephen@networkplumber.org>
2025-12-07 19:19     ` |SUCCESS| pw159227 [PATCH v5 16/17] vhost: check for overflow in xstat name checkpatch
2025-12-16 16:12     ` 0-day Robot
     [not found]   ` <20251207191242.165619-16-stephen@networkplumber.org>
2025-12-07 19:19     ` |SUCCESS| pw159226 [PATCH v5 15/17] ethdev: avoid possible overflow in xstat names checkpatch
2025-12-16 16:12     ` 0-day Robot
     [not found]   ` <20251207191242.165619-3-stephen@networkplumber.org>
2025-12-16 16:12     ` |SUCCESS| pw159213 [PATCH v5 02/17] lpm: restrict name size 0-day Robot
     [not found]   ` <20251207191242.165619-4-stephen@networkplumber.org>
2025-12-16 16:12     ` 0-day Robot [this message]
     [not found]   ` <20251207191242.165619-7-stephen@networkplumber.org>
2025-12-07 19:17     ` |WARNING| pw159217 [PATCH v5 06/17] telemetry: avoid possible string overflow checkpatch
2025-12-16 16:12     ` |SUCCESS| " 0-day Robot
     [not found]   ` <20251207191242.165619-8-stephen@networkplumber.org>
2025-12-07 19:17     ` |SUCCESS| pw159218 [PATCH v5 07/17] efd: handle possible name truncation checkpatch
2025-12-16 16:12     ` 0-day Robot
     [not found]   ` <20251207191242.165619-12-stephen@networkplumber.org>
2025-12-07 19:16     ` |SUCCESS| pw159222 [PATCH v5 11/17] eal: limit maximum runtime directory and socket paths checkpatch
2025-12-16 16:12     ` 0-day Robot
     [not found]   ` <20251207191242.165619-13-stephen@networkplumber.org>
2025-12-07 19:15     ` |SUCCESS| pw159223 [PATCH v5 12/17] eal: check for hugefile path overflow checkpatch
2025-12-16 16:12     ` 0-day Robot
     [not found]   ` <20251207191242.165619-14-stephen@networkplumber.org>
2025-12-07 19:14     ` |SUCCESS| pw159224 [PATCH v5 13/17] eal: check tailq length checkpatch
2025-12-16 16:12     ` 0-day Robot

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=20251216161202.762473-1-robot@bytheb.org \
    --to=robot@bytheb.org \
    --cc=stephen@networkplumber.org \
    --cc=test-report@dpdk.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).