Re: [PATCH v5 net 10/10] octeontx2-af: npc: cn20k: Reject missing default-rule MCAM indices

[Ratheesh Kannoth]

On 2026-04-29 at 07:57:22, Ratheesh Kannoth (rkannoth@xxxxxxxxxxx) wrote:
> When cn20k default L2 rules are not installed,
> npc_cn20k_dft_rules_idx_get() leaves broadcast, multicast, promiscuous, and
> unicast slots at USHRT_MAX. npc_get_nixlf_mcam_index() previously returned
> that sentinel as a valid MCAM index, so callers could program hardware with
> an invalid index.
>
> Return -EINVAL from the cn20k branches of npc_get_nixlf_mcam_index() when
> the requested slot is still USHRT_MAX. Harden cn20k NPC MCAM entry helpers
> to reject out-of-range indices before touching hardware.
>
> Drop the early bounds check in npc_enable_mcam_entry() for cn20k so invalid
> indices are validated inside npc_cn20k_enable_mcam_entry() instead of being
> silently ignored.
>
> In rvu_npc_update_flowkey_alg_idx(), treat negative MCAM indices like
> out-of-range values, and only update RSS actions for promiscuous and
> all-multi paths when the resolved index is non-negative.
>

> diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc.c
> index 5d349d131fdb..3c814d157ab9 100644
> --- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc.c
> +++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc.c
> @@ -163,14 +163,35 @@ int npc_get_nixlf_mcam_index(struct npc_mcam *mcam,
>  		if (rc)
>  			return -EFAULT;
>
> +		if (is_lbk_vf(rvu, pcifunc)) {
> +			if (promisc == USHRT_MAX)
> +				return -EINVAL;
> +			return promisc;
> +		}
> +
[ ... ]
> @@ -3897,6 +4006,12 @@ int rvu_mbox_handler_npc_read_base_steer_rule(struct rvu *rvu,
>  	/* Read the default ucast entry if there is no pkt steering rule */
>  	index = npc_get_nixlf_mcam_index(mcam, pcifunc, nixlf,
>  					 NIXLF_UCAST_ENTRY);
> +	if (index < 0) {
> +		mutex_unlock(&mcam->lock);
> +		rc = NIX_AF_ERR_AF_LF_INVALID;
> +		goto out;
> +	}
> +
>Could this change cause a regression in the cn20k-specific base steer rule
>handler?
>While this generic handler correctly returns an explicit error when
>npc_get_nixlf_mcam_index() returns a negative value, it looks like
>rvu_mbox_handler_npc_cn20k_read_base_steer_rule() in
>drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c was missed.
>In that function, rc is 0 from the preceding successful call to
>nix_get_nixlf():
This is not an issue introduced by this fix patch. I agree that this is an issue, but should
be addressed as another net patch as fix.

>While this generic handler correctly returns an explicit error when
>npc_get_nixlf_mcam_index() returns a negative value, it looks like
>rvu_mbox_handler_npc_cn20k_read_base_steer_rule() in
>drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c was missed.
>In that function, rc is 0 from the preceding successful call to
>nix_get_nixlf():
>drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c:
>rvu_mbox_handler_npc_cn20k_read_base_steer_rule() {
    ...
	rc = nix_get_nixlf(rvu, pcifunc, &nixlf, NULL);
	if (rc < 0) {
		mutex_unlock(&mcam->lock);
		goto out;
	}
	rl_type = rvu_npc_get_base_steer_rule_type(rvu, pcifunc);
	/* Read the default ucast entry if there is no pkt steering rule */
	index = npc_get_nixlf_mcam_index(mcam, pcifunc, nixlf, rl_type);
	if (index < 0) {
		mutex_unlock(&mcam->lock);
		goto out;
	}
    ...
out:
	return rc;
}
>Does this now silently return 0 (Success) instead of propagating the error
>when index < 0? This seems like it could leak an uninitialized or zeroed
>rsp->entry payload back to the VF.
This is not an issue introduced by this fix patch. I agree that this is an issue, but should
be addressed as another net patch as fix.