Re: [PATCH v3 net 06/11] octeontx2-af: npc: cn20k: Clear MCAM entries by index and key width

Ratheesh Kannoth
2026-04-27T03:44:49Z

On 2026-04-23 at 16:13:12, Ratheesh Kannoth (rkannoth@marvell.com) wrote:
> Replace the old four-argument CN20K MCAM clear with a per-bank static
> helper and npc_cn20k_clear_mcam_entry() that takes a logical MCAM index,

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

> @@ -755,9 +762,15 @@ void rvu_npc_install_promisc_entry(struct rvu *rvu, u16 pcifunc,
>
> /* If the corresponding PF's ucast action is RSS,
> * use the same action for promisc also
> + * Please note that for lbk(s) "index" and "ucast_idx"
> + * will be same.
> */
> - ucast_idx = npc_get_nixlf_mcam_index(mcam, pcifunc,
> - nixlf, NIXLF_UCAST_ENTRY);
> + if (is_lbk_vf(rvu, pcifunc))
> + ucast_idx = index;
> + else
> + ucast_idx = npc_get_nixlf_mcam_index(mcam, pcifunc,
> + nixlf, NIXLF_UCAST_ENTRY);
> +
Should this LBK VF handling also be applied to rvu_npc_install_allmulti_entry()
and rvu_npc_update_flowkey_alg_idx()?
It looks like rvu_npc_install_allmulti_entry() tries to skip LBK VFs but uses
an impossible condition:
if (is_lbk_vf(...) && is_sdp_vf(...))
Since a VF cannot be both simultaneously, LBK VFs proceed and call
npc_get_nixlf_mcam_index() for NIXLF_ALLMULTI_ENTRY and NIXLF_UCAST_ENTRY.
For LBK VFs, npc_cn20k_dft_rules_idx_get() only populates the promisc pointer
and returns 0, leaving the stack variables for mcast and ucast uninitialized.
These uninitialized values might then be used to read and write hardware
rules via rvu_mbox_handler_npc_install_flow(), potentially corrupting MCAM
rules.

Agree, but this bug is introduced by a different commit. But the change
"Patch 6: [PATCH v3 net 06/11] octeontx2-af: npc: cn20k: Clear MCAM entries by index and key width"
is a bug fix and is for another issue. So dont want to club it with this and will be addressed
in a followup patch; that will be posted once this patch series is merged.

Similarly, rvu_npc_update_flowkey_alg_idx() retrieves NIXLF_UCAST_ENTRY
without checking for LBK VFs, which might lead to the same uninitialized read.
Even if later commits in this series initialize these variables to zero, could
that just cause deterministic corruption of MCAM index 0 instead of random
memory corruption, unless LBK VFs are properly handled or skipped in these
functions as well?

Agree, but this bug is introduced by a different commit. But the change
"Patch 6: [PATCH v3 net 06/11] octeontx2-af: npc: cn20k: Clear MCAM entries by index and key width"
is a bug fix and is for another issue. So dont want to club it with this and will be addressed
in a followup patch; that will be posted once this patch series is merged.