|SUCCESS| [2/2] mailmap: add Denis Sergeev

dpdklab at iol.unh.edu dpdklab at iol.unh.edu
Tue May 19 10:41:14 CEST 2026


Test-Label: ai-code-review
Test-Status: SUCCESS
https://dpdk.org/patch/164103

_AI Code Review_

=== Patch Review: series.patch (via Claude) ===
Review date: 2026-05-19

80317ff6adfd
Author: Denis Sergeev <denserg.edu at gmail.com>
net/bnxt/tf_core: fix ignored return of EM delete

This patch series addresses a return value handling bug in the bnxt
driver and adds a mailmap entry.

> diff --git a/drivers/net/bnxt/tf_core/v3/tfc_em.c b/drivers/net/bnxt/tf_core/v3/tfc_em.c
> index 3fe4dbe3fe..4c126dc2f4 100644
> --- a/drivers/net/bnxt/tf_core/v3/tfc_em.c
> +++ b/drivers/net/bnxt/tf_core/v3/tfc_em.c
> @@ -661,6 +661,11 @@ int tfc_em_delete(struct tfc *tfcp, struct tfc_em_delete_parms *parms)
>  			       &db_offset
>  #endif
>  			       );
> +	if (rc != 0) {
> +		PMD_DRV_LOG_LINE(ERR, "tfc_em_delete_raw() failed: %s",
> +				 strerror(-rc));
> +		return -EINVAL;
> +	}

Does tfc_em_delete_raw() consistently return negative error codes? The
use of strerror(-rc) assumes rc is negative. If tfc_em_delete_raw() can
return positive errno values, does this create issues?

Why does the function return -EINVAL specifically when
tfc_em_delete_raw() could fail for multiple reasons? Is rc from
tfc_em_delete_raw() not appropriate to return directly to the caller?

After this check, does the rest of tfc_em_delete() continue to overwrite
rc with subsequent operations? If tfc_cpm_get_cmm_inst() later in the
function still overwrites rc without checking, does the fix fully address
the original issue?

>  
>  	record_offset = REMOVE_POOL_FROM_OFFSET(pi.lkup_pool_sz_exp,
>  						record_offset);

[ ... ]


More information about the test-report mailing list