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

[Ratheesh Kannoth <rkannoth@marvell.com>]

On 2026-04-23 at 16:13:17, Ratheesh Kannoth (rkannoth@marvell.com) wrote:

>> diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc.c
>> index 5d349d131fdb..611cd7fce245 100644
>> --- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc.c
>> +++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc.c
>
>[ ... ]
>
>> @@ -3897,6 +4006,13 @@ 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) {
>> +		dev_err(rvu->dev,
>> +			"%s: Error to get ucast entry for pcifunc=%#x\n",
>> +			__func__, pcifunc);
>> +		goto out;
>> +	}
>> +
>>  read_entry:
>>  	/* Read the mcam entry */
>>  	npc_read_mcam_entry(rvu, mcam, blkaddr, index, &rsp->entry, &intf,
>
>Does this 'goto out' leak mcam->lock?  Looking at the function entry,
>the lock is acquired before the for-loop:
>
>rvu_mbox_handler_npc_read_base_steer_rule() {
>    ...
>    mutex_lock(&mcam->lock);
>
>    for (idx = 0; idx < pfvf->def_ucast_rule.count; idx++) {
>        ...
>    }
>
>    /* Read the default ucast entry if there is no pkt steering rule */
>    index = npc_get_nixlf_mcam_index(...);
>    if (index < 0) {
>        goto out;
>    }
>
>and the 'out' label just returns without unlocking:
>
>out:
>    return rc;
>
>The nix_get_nixlf() failure path just before this does:
>
>    if (rc) {
>        mutex_unlock(&mcam->lock);
>        goto out;
>    }
>
>Should this new error path match that pattern?

AI review report: https://netdev-ai.bots.linux.dev/ai-review.html?id=9923f145-31df-46b0-84e8-b15f1e307ad2#patch-10
pw-bot: changes-requested

Will fix in next version.