Re: [PATCH v3 net 01/11] octeontx2-af: npc: cn20k: Propagate MCAM key-type errors on cn20k

[Ratheesh Kannoth]

On 2026-04-23 at 16:13:07, Ratheesh Kannoth (rkannoth@xxxxxxxxxxx) wrote:
> npc_mcam_idx_2_key_type() can fail; callers used to ignore it and still
> used kw_type when enabling, configuring, copying, and reading MCAM
> entries. That could program or decode hardware with an undefined key
> type.
>

>https://sashiko.dev/#/patchset/20260423104317.2707923-1-rkannoth%40marvell.com
>
>> @@ -1415,14 +1435,14 @@ int rvu_mbox_handler_npc_cn20k_mcam_alloc_and_write_entry(struct rvu *rvu,
>>  	else
>>  		nix_intf = pfvf->nix_rx_intf;
>>
>> -	npc_cn20k_config_mcam_entry(rvu, blkaddr, entry, nix_intf,
>> -				    &req->entry_data, req->enable_entry,
>> -				    req->hw_prio, req->req_kw_type);
>> +	rc = npc_cn20k_config_mcam_entry(rvu, blkaddr, entry, nix_intf,
>> +					 &req->entry_data, req->enable_entry,
>> +					 req->hw_prio, req->req_kw_type);
>>
>>  	mutex_unlock(&mcam->lock);
>>
>>  	rsp->entry = entry_rsp.entry;
>> -	return 0;
>> +	return rc;
>>  }
>Does this code leak the allocated MCAM entry if npc_cn20k_config_mcam_entry()
>fails?
>Earlier in rvu_mbox_handler_npc_cn20k_mcam_alloc_and_write_entry(), an entry
>is successfully allocated via rvu_mbox_handler_npc_mcam_alloc_entry(). If
>the configuration step then fails, returning rc without rolling back the
>allocation leaves the hardware MCAM entry unmapped but still reserved.
>Because the generic mailbox framework propagates the error code, the
>requester will assume the entire allocation failed and will never send a
>free request. This could allow a VF to repeatedly trigger this failure path
>and exhaust all available MCAM entries.
This commit is to address a smatch error reported by Dan. To fix issue, raised here
by sashiko, we need to change multiple files to handle all errors gracefully. it will be an enhancement change.
I will add a follow up patch to net-next. Ignoring this comment for this patch.