Re: [net-next,PatchV3,2/2] Octeontx2-pf: Add support for DMAC_FILTER trap

[Jakub Kicinski <kuba@kernel.org>]

This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.

For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
Octeontx2-pf: Add support for DMAC_FILTER trap

This patch adds devlink trap support for DMAC_FILTER, allowing users to
monitor packets dropped by the DMAC filter via the devlink interface.

> diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c
> index a7feb4c392b3..2fafdf405c33 100644
> --- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c
> +++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c

[ ... ]

> @@ -3282,6 +3282,10 @@ static int otx2_probe(struct pci_dev *pdev, const struct pci_device_id *id)
>  	if (err)
>  		goto err_mcam_flow_del;
>
> +	err = otx2_devlink_traps_register(pf);
> +	if (err)
> +		goto err_mcam_flow_del;

If otx2_devlink_traps_register() fails here, the error path jumps to
err_mcam_flow_del. However, otx2_register_dl() was called earlier in
otx2_probe() and succeeded. Should there be a call to otx2_unregister_dl()
on this error path to avoid leaking the devlink structure?

Looking at otx2_remove(), the cleanup order is:

    otx2_devlink_traps_unregister(pf);
    otx2_unregister_dl(pf);

But the err_mcam_flow_del path does not call either of these functions.
-- 
pw-bot: cr