[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aXrutHgsKEuJUlGK@rkannoth-OptiPlex-7090>
Date: Thu, 29 Jan 2026 10:53:00 +0530
From: Ratheesh Kannoth <rkannoth@...vell.com>
To: Jakub Kicinski <kuba@...nel.org>
CC: <edumazet@...gle.com>, <sumang@...vell.com>,
<linux-kernel@...r.kernel.org>, <sbhatta@...vell.com>,
<davem@...emloft.net>, <netdev@...r.kernel.org>, <pabeni@...hat.com>,
<andrew+netdev@...n.ch>, <sgoutham@...vell.com>
Subject: Re: [net-next,v6,01/13] octeontx2-af: npc: cn20k: Index management
On 2026-01-29 at 10:43:01, Jakub Kicinski (kuba@...nel.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 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 across the new subbank
> architecture with 32 subbanks of 256 entries each.
>
> > 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..30cc05c64487
> > --- /dev/null
> > +++ b/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c
>
> [ ... ]
>
> > +static int npc_create_srch_order(int cnt)
> > +{
> > + int val = 0;
> > +
> > + subbank_srch_order = kcalloc(cnt, sizeof(int),
> > + GFP_KERNEL);
> > + if (!subbank_srch_order)
> > + return -ENOMEM;
> > +
> > + for (int i = 0; i < cnt; i += 2) {
> > + subbank_srch_order[i] = cnt / 2 - val - 1;
> > + subbank_srch_order[i + 1] = cnt / 2 + 1 + val;
> ^^^^^
>
> When cnt is odd, the final loop iteration has i = cnt - 1, which means
> subbank_srch_order[i + 1] writes to index cnt, which is out of bounds.
>
> For example with cnt = 5, the loop iterates with i = 0, 2, 4. At i = 4,
> the array access subbank_srch_order[5] overflows the allocated array of
> 5 elements.
>
> While CN20K hardware typically has 32 subbanks (even), the value is read
> from a hardware register at npc_priv_init() without validation beyond
> checking for zero. Could this lead to memory corruption if the hardware
> reports an odd subbank count?
subbank count is 16 or 8, depending on SoC variant. i will add a WARN check on
odd ?
>
> > + val++;
> > + }
> > +
> > + subbank_srch_order[cnt - 1] = cnt / 2;
> > + return 0;
> > +}
>
> [ ... ]
> --
> pw-bot: cr
Powered by blists - more mailing lists