From: Jakub Kicinski <kuba@kernel.org>
To: rkannoth@marvell.com
Cc: Jakub Kicinski <kuba@kernel.org>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [net-next,v4,01/13] octeontx2-af: npc: cn20k: Index management
Date: Sat, 17 Jan 2026 16:40:17 -0800 [thread overview]
Message-ID: <20260118004017.1044291-1-kuba@kernel.org> (raw)
In-Reply-To: <20260113101658.4144610-2-rkannoth@marvell.com>
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-af: npc: cn20k: Index management
This patch adds MCAM index management for CN20K silicon, implementing
contiguous and non-contiguous allocation schemes with reference, limit,
and priority parameters across the new subbank architecture.
> diff --git a/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c b/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c
> new file mode 100644
> index 000000000000..ebccc780ab8e
> --- /dev/null
> +++ b/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c
[ ... ]
> +static int npc_idx_free(struct rvu *rvu, u16 *mcam_idx, int count,
> + bool maps_del)
> +{
> + struct npc_subbank *sb;
> + int idx, i;
> + bool ret;
> + int rc;
> +
> + for (i = 0; i < count; i++) {
> + rc = npc_mcam_idx_2_subbank_idx(rvu, mcam_idx[i],
> + &sb, &idx);
> + if (rc)
> + return rc;
> +
> + ret = npc_subbank_free(rvu, sb, idx);
> + if (ret)
> + return -EINVAL;
If an error occurs partway through this loop, for example when freeing
entry i out of count entries, entries from i+1 to count-1 remain allocated
but are never freed. Could this leak MCAM slots when npc_idx_free() is
called from error paths in npc_multi_subbank_ref_alloc() or
npc_subbank_noref_alloc()?
> +
> + if (!maps_del)
> + continue;
> +
> + rc = npc_del_from_pf_maps(rvu, mcam_idx[i]);
> + if (rc)
> + return rc;
> + }
> +
> + return 0;
> +}
[ ... ]
> +static int npc_priv_init(struct rvu *rvu)
> +{
[ ... ]
> + npc_priv.sb = kcalloc(num_subbanks, sizeof(struct npc_subbank),
> + GFP_KERNEL);
> + if (!npc_priv.sb)
> + return -ENOMEM;
> +
> + xa_init_flags(&npc_priv.xa_sb_used, XA_FLAGS_ALLOC);
> + xa_init_flags(&npc_priv.xa_sb_free, XA_FLAGS_ALLOC);
> + xa_init_flags(&npc_priv.xa_idx2pf_map, XA_FLAGS_ALLOC);
> + xa_init_flags(&npc_priv.xa_pf_map, XA_FLAGS_ALLOC);
> +
> + if (npc_create_srch_order(num_subbanks)) {
> + kfree(npc_priv.sb);
> + return -ENOMEM;
> + }
The four xarrays initialized above are not destroyed before returning
here. Should xa_destroy() be called for xa_sb_used, xa_sb_free,
xa_idx2pf_map, and xa_pf_map on this error path?
[ ... ]
> + npc_priv.xa_pf2idx_map = kcalloc(npc_priv.pf_cnt,
> + sizeof(struct xarray),
> + GFP_KERNEL);
> + if (!npc_priv.xa_pf2idx_map) {
> + kfree(subbank_srch_order);
> + kfree(npc_priv.sb);
> + return -ENOMEM;
> + }
Same question here - the four xarrays are still not destroyed on this
error path.
> +
> + for (i = 0; i < npc_priv.pf_cnt; i++)
> + xa_init_flags(&npc_priv.xa_pf2idx_map[i], XA_FLAGS_ALLOC);
> +
> + return 0;
> +}
--
pw-bot: cr
next prev parent reply other threads:[~2026-01-18 0:40 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-13 10:16 [PATCH net-next v4 00/13] NPC HW block support for cn20k Ratheesh Kannoth
2026-01-13 10:16 ` [PATCH net-next v4 01/13] octeontx2-af: npc: cn20k: Index management Ratheesh Kannoth
2026-01-18 0:39 ` Jakub Kicinski
2026-01-19 4:04 ` Ratheesh Kannoth
2026-01-18 0:40 ` Jakub Kicinski [this message]
2026-01-19 4:00 ` [net-next,v4,01/13] " Ratheesh Kannoth
2026-01-13 10:16 ` [PATCH net-next v4 02/13] octeontx2-af: npc: cn20k: KPM profile changes Ratheesh Kannoth
2026-01-13 10:16 ` [PATCH net-next v4 03/13] octeontx2-af: npc: cn20k: Add default profile Ratheesh Kannoth
2026-01-13 10:16 ` [PATCH net-next v4 04/13] ocetontx2-af: npc: cn20k: MKEX profile support Ratheesh Kannoth
2026-01-18 0:40 ` [net-next,v4,04/13] " Jakub Kicinski
2026-01-19 4:17 ` Ratheesh Kannoth
2026-01-20 3:24 ` Ratheesh Kannoth
2026-01-13 10:16 ` [PATCH net-next v4 05/13] octeontx2-af: npc: cn20k: Allocate default MCAM indexes Ratheesh Kannoth
2026-01-18 0:40 ` [net-next,v4,05/13] " Jakub Kicinski
2026-01-19 3:42 ` Ratheesh Kannoth
2026-01-19 17:32 ` Jakub Kicinski
2026-01-20 1:37 ` Ratheesh Kannoth
2026-01-13 10:16 ` [PATCH net-next v4 06/13] octeontx2-af: npc: cn20k: Use common APIs Ratheesh Kannoth
2026-01-13 10:16 ` [PATCH net-next v4 07/13] octeontx2-af: npc: cn20k: Prepare for new SoC Ratheesh Kannoth
2026-01-22 8:36 ` Simon Horman
2026-01-23 15:39 ` Ratheesh Kannoth
2026-01-13 10:16 ` [PATCH net-next v4 08/13] octeontx2-af: npc: cn20k: Add new mailboxes for CN20K silicon Ratheesh Kannoth
2026-01-13 10:16 ` [PATCH net-next v4 09/13] octeontx2-af: npc: cn20k: virtual index support Ratheesh Kannoth
2026-01-18 0:40 ` [net-next,v4,09/13] " Jakub Kicinski
2026-01-19 3:39 ` Ratheesh Kannoth
2026-01-13 10:16 ` [PATCH net-next v4 10/13] octeontx2-af: npc: cn20k: Allocate MCAM entry for flow installation Ratheesh Kannoth
2026-01-13 10:16 ` [PATCH net-next v4 11/13] octeontx2-pf: cn20k: Add TC rules support Ratheesh Kannoth
2026-01-18 0:40 ` [net-next,v4,11/13] " Jakub Kicinski
2026-01-19 3:39 ` Ratheesh Kannoth
2026-01-13 10:16 ` [PATCH net-next v4 12/13] octeontx2-af: npc: cn20k: add debugfs support Ratheesh Kannoth
2026-01-13 10:16 ` [PATCH net-next v4 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=20260118004017.1044291-1-kuba@kernel.org \
--to=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=rkannoth@marvell.com \
/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