Re: [PATCH v18 net-next 1/8] octeontx2-af: npc: cn20k: debugfs enhancements

[Ratheesh Kannoth <rkannoth@marvell.com>]

On 2026-06-02 at 11:33:52, Ratheesh Kannoth (rkannoth@marvell.com) wrote:
> Improve MCAM visibility and field debugging for CN20K NPC.
>
> - Extend "mcam_layout" to show enabled (+) or disabled state per entry
>   so status can be verified without parsing the full "mcam_entry" dump.
> - Add "dstats" debugfs entry: for enabled MCAM indices, print hit deltas
>   since the prior read by comparing hardware counters to a per-entry
>   software baseline and advancing that baseline after each read (hardware
>   counters are not cleared).
> - Add "mismatch" debugfs entry: lists MCAM entries that are enabled
>   but not explicitly allocated, helping diagnose allocation/field issues.
>
> Signed-off-by: Ratheesh Kannoth <rkannoth@marvell.com>

https://sashiko.dev/#/patchset/20260602060359.1894952-1-rkannoth%40marvell.com
sashiko says

>> +			pf = 0xFFFF;
>> +			map = xa_load(&npc_priv->xa_idx2pf_map, mcam_idx);
>> +			if (map)
>> +				pf = xa_to_value(map);
>> +
>> +			delta = stats - dstats[bank][idx];
>> +
>> +			snprintf(buff, sizeof(buff), "%u\t%#04x\t%llu\n",
>> +				 mcam_idx, pf, delta);
>> +			seq_puts(s, buff);
>> +
>> +			dstats[bank][idx] = stats;
>Does this code allow an out-of-bounds array access?
No.

>In npc_priv_init() (shown below), integer division truncation allows
>a hardware-supplied bank_depth to exceed statically allocated array
>dimensions. Because remainders are truncated, a bank_depth value such
>as 8223 (with num_subbanks = 32) yields subbank_depth = 256.

npc_priv_init() do check against max limit for MAX_BANKDEPTH and bail out on
error.

>I noticed this was fixed later in the series in commit "octeontx2-af: npc:
>cn20k: Allocate npc_priv and dstats dynamically.", but this patch
>introduces a concrete buffer overflow.

These checks are in the current patch itself.

>+update_en_map:
>> +	if (enable)
>> +		set_bit(index, npc_priv.en_map);
>Can index exceed the bitmap size here?
>Due to the same integer division truncation issue mentioned above, index
>can exceed the expected bounds, causing set_bit() to write beyond the
>statically allocated 16384 bits of npc_priv.en_map.
No. "en_map" bitmap is defined with MAXimum size possible. Check against these max limits
are done during probe (in npc_priv_init()) and returns error.

>  	subbank_depth =	bank_depth / num_subbanks;
>> +	if (subbank_depth > MAX_SUBBANK_DEPTH) {
>This is a pre-existing issue, but can this integer division evaluate to 0?
>If hardware reports a banksize (which becomes bank_depth) less than
>num_subbanks (e.g., 16 vs 32), the integer division evaluates to 0.
Pre-existing issue, so not addressing here. We need to check agaist zero, wll post
as a seperate patch to "net" tree, - or may be a hardening series.