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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.