[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20260122022521.2531255-1-kuba@kernel.org>
Date: Wed, 21 Jan 2026 18:25:21 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: hkelam@...vell.com
Cc: Jakub Kicinski <kuba@...nel.org>,
netdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [net-next,PatchV3,2/2] Octeontx2-pf: Add support for DMAC_FILTER trap
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
Powered by blists - more mailing lists