|SUCCESS| pw159218 [PATCH v5 07/17] efd: handle possible name truncation

[0-day Robot]

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

_AI Review Comments Available_

git sha: [Cannot determine from patch format]
Author: Stephen Hemminger <stephen at networkplumber.org>
efd: handle possible name truncation

This commit adds checking for name truncation when converting EFD names
to ring names and improves error logging when ring creation fails.

> diff --git a/lib/efd/rte_efd.c b/lib/efd/rte_efd.c
> index ebf1e0655f..ed2c509938 100644
> --- a/lib/efd/rte_efd.c
> +++ b/lib/efd/rte_efd.c
> @@ -698,12 +698,15 @@ rte_efd_create(const char *name, uint32_t max_num_rules, uint32_t key_len,
>  	TAILQ_INSERT_TAIL(efd_list, te, next);
>  	rte_mcfg_tailq_write_unlock();
> 
> -	snprintf(ring_name, sizeof(ring_name), "HT_%s", table->name);
> +	if (snprintf(ring_name, sizeof(ring_name), "HT_%s", table->name)
> +	    >= (int)sizeof(ring_name))
> +		EFD_LOG(NOTICE, "EFD ring name truncated to '%s'", ring_name);

Can this truncation lead to ring name collisions? If two EFD tables have
very long names that differ only in their endings, they might result in 
identical truncated ring names after adding the "HT_" prefix. The code
checks for truncation in rte_efd_create() but continues execution even
when truncation occurs, which could cause rte_ring_create() to fail with
EEXIST if another ring with the same truncated name already exists.

> +
>  	/* Create ring (Dummy slot index is not enqueued) */
>  	r = rte_ring_create(ring_name, rte_align32pow2(table->max_num_rules),
>  			offline_cpu_socket, 0);
>  	if (r == NULL) {
> -		EFD_LOG(ERR, "memory allocation failed");
> +		EFD_LOG(ERR, "ring creation failed: %s", rte_strerror(rte_errno));
>  		rte_efd_free(table);
>  		return NULL;
>  	}