From: Ratheesh Kannoth <rkannoth@marvell.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: <netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [net-next,v3,05/13] octeontx2-af: npc: cn20k: Allocate default MCAM indexes
Date: Tue, 13 Jan 2026 15:26:33 +0530 [thread overview]
Message-ID: <aWYW0cbXn2ew9igB@rkannoth-OptiPlex-7090> (raw)
In-Reply-To: <20260110225935.3900857-1-kuba@kernel.org>
On 2026-01-11 at 04:29:35, Jakub Kicinski (kuba@kernel.org) wrote:
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least pausible.
>
> For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
> ---
> octeontx2-af: npc: cn20k: Allocate default MCAM indexes
>
> This patch allocates MCAM indexes for promiscuous, multicast, broadcast,
> and unicast traffic when the NIX LF is attached to the PF/VF, rather than
> reserving entries upfront.
>
> > diff --git a/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c b/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c
> > index 88d7f65d246c..cc5a2fde02b9 100644
> > --- a/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c
> > +++ b/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c
>
> [ ... ]
>
> > +int npc_cn20k_dft_rules_alloc(struct rvu *rvu, u16 pcifunc)
> > +{
> > + u16 mcam_idx[4] = { 0 }, pf_ucast, pf_pcifunc;
> > + struct npc_mcam_alloc_entry_req req = { 0 };
> > + struct npc_mcam_alloc_entry_rsp rsp = { 0 };
>
> [ ... ]
>
> > + ret = rvu_mbox_handler_npc_mcam_alloc_entry(rvu, &req, &rsp);
> > +
> > + /* successfully allocated index */
> > + if (!ret) {
> > + /* Copy indexes to local array */
> > + for (i = 0; i < cnt; i++)
> > + mcam_idx[i] = rsp.entry_list[i];
> > +
> > + goto chk_sanity;
> > + }
>
> [ ... ]
>
> > +chk_sanity:
>
> [ ... ]
>
> > + /* LBK */
> > + if (is_lbk_vf(rvu, pcifunc)) {
> > + index = NPC_DFT_RULE_ID_MK(pcifunc, NPC_DFT_RULE_PROMISC_ID);
> > + ret = xa_insert(&npc_priv.xa_pf2dfl_rmap, index,
> > + xa_mk_value(mcam_idx[0]), GFP_KERNEL);
> > + if (ret) {
>
> [ ... ]
>
> > + ret = -EFAULT;
> > + goto err;
> > + }
> > +
> > + goto done;
> > + }
> > +
> > + /* VF */
> > + if (is_vf(pcifunc)) {
> > + index = NPC_DFT_RULE_ID_MK(pcifunc, NPC_DFT_RULE_UCAST_ID);
> > + ret = xa_insert(&npc_priv.xa_pf2dfl_rmap, index,
> > + xa_mk_value(mcam_idx[0]), GFP_KERNEL);
> > + if (ret) {
>
> [ ... ]
>
> > + ret = -EFAULT;
> > + goto err;
> > + }
> > +
> > + goto done;
> > + }
> > +
> > + /* PF */
> > + for (i = NPC_DFT_RULE_START_ID, k = 0; i < NPC_DFT_RULE_MAX_ID &&
> > + k < cnt; i++, k++) {
> > + index = NPC_DFT_RULE_ID_MK(pcifunc, i);
> > + ret = xa_insert(&npc_priv.xa_pf2dfl_rmap, index,
> > + xa_mk_value(mcam_idx[k]), GFP_KERNEL);
> > + if (ret) {
>
> [ ... ]
>
> > + ret = -EFAULT;
> > + goto err;
> > + }
> > + }
> > +
> > +done:
> > + return 0;
> > +err:
> > + /* TODO: handle errors */
> > + return ret;
> > +}
>
> If xa_insert() fails here, the MCAM entries that were allocated earlier
> via rvu_mbox_handler_npc_mcam_alloc_entry() are not freed before
> returning the error. Could this leak the MCAM entries?
>
> The comment indicates this is known incomplete error handling. For the
> PF case, partial xa_insert failures in the loop could also leave some
> entries inserted in the xarray while others are not, leading to an
> inconsistent state.
ACK
next prev parent reply other threads:[~2026-01-13 9:56 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-09 5:48 [PATCH net-next v3 00/13] NPC HW block support for cn20k Ratheesh Kannoth
2026-01-09 5:48 ` [PATCH net-next v3 01/13] octeontx2-af: npc: cn20k: Index management Ratheesh Kannoth
2026-01-10 22:51 ` Jakub Kicinski
2026-01-13 10:08 ` Ratheesh Kannoth
2026-01-10 22:58 ` Jakub Kicinski
2026-01-13 10:29 ` Ratheesh Kannoth
2026-01-13 15:07 ` Jakub Kicinski
2026-01-14 5:52 ` Ratheesh Kannoth
2026-01-15 3:14 ` Jakub Kicinski
2026-01-10 22:59 ` [net-next,v3,01/13] " Jakub Kicinski
2026-01-13 10:08 ` Ratheesh Kannoth
2026-01-09 5:48 ` [PATCH net-next v3 02/13] octeontx2-af: npc: cn20k: KPM profile changes Ratheesh Kannoth
2026-01-09 5:48 ` [PATCH net-next v3 03/13] octeontx2-af: npc: cn20k: Add default profile Ratheesh Kannoth
2026-01-09 5:48 ` [PATCH net-next v3 04/13] ocetontx2-af: npc: cn20k: MKEX profile support Ratheesh Kannoth
2026-01-10 22:59 ` [net-next,v3,04/13] " Jakub Kicinski
2026-01-13 10:02 ` Ratheesh Kannoth
2026-01-09 5:48 ` [PATCH net-next v3 05/13] octeontx2-af: npc: cn20k: Allocate default MCAM indexes Ratheesh Kannoth
2026-01-10 22:52 ` Jakub Kicinski
2026-01-13 9:58 ` Ratheesh Kannoth
2026-01-10 22:59 ` [net-next,v3,05/13] " Jakub Kicinski
2026-01-13 9:56 ` Ratheesh Kannoth [this message]
2026-01-09 5:48 ` [PATCH net-next v3 06/13] octeontx2-af: npc: cn20k: Use common APIs Ratheesh Kannoth
2026-01-09 5:48 ` [PATCH net-next v3 07/13] octeontx2-af: npc: cn20k: Prepare for new SoC Ratheesh Kannoth
2026-01-09 5:48 ` [PATCH net-next v3 08/13] octeontx2-af: npc: cn20k: Add new mailboxes for CN20K silicon Ratheesh Kannoth
2026-01-09 5:48 ` [PATCH net-next v3 09/13] octeontx2-af: npc: cn20k: virtual index support Ratheesh Kannoth
2026-01-10 22:52 ` Jakub Kicinski
2026-01-13 10:09 ` Ratheesh Kannoth
2026-01-09 5:48 ` [PATCH net-next v3 10/13] octeontx2-af: npc: cn20k: Allocate MCAM entry for flow installation Ratheesh Kannoth
2026-01-09 5:48 ` [PATCH net-next v3 11/13] octeontx2-pf: cn20k: Add TC rules support Ratheesh Kannoth
2026-01-10 22:59 ` [net-next,v3,11/13] " Jakub Kicinski
2026-01-13 9:54 ` Ratheesh Kannoth
2026-01-09 5:48 ` [PATCH net-next v3 12/13] octeontx2-af: npc: cn20k: add debugfs support Ratheesh Kannoth
2026-01-09 5:48 ` [PATCH net-next v3 13/13] octeontx2-af: npc: Use common structures Ratheesh Kannoth
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=aWYW0cbXn2ew9igB@rkannoth-OptiPlex-7090 \
--to=rkannoth@marvell.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.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