Re: [PATCH v14 net-next 6/9] octeontx2: cn20k: Coordinate default rules with NIX LF lifecycle

[Ratheesh Kannoth]

On 2026-05-14 at 11:55:34, Ratheesh Kannoth (rkannoth@xxxxxxxxxxx) wrote:
> Add NIX_LF_DONT_FREE_DFT_IDXS so the PF can send NIX LF free during hw
> reinit or teardown without the AF freeing CN20K default NPC rule indexes
> while the driver still owns that state (otx2_init_hw_resources and
> otx2_free_hw_resources).
>
> On CN20K, allocate default NPC rules from NIX LF alloc before
> nix_interface_init, roll back with npc_cn20k_dft_rules_free on failure,
> and free from NIX LF free when the new flag is not set. Tighten
> rvu_mbox_handler_nix_lf_alloc error handling: use a single rc, propagate
> qmem_alloc and other errors, and set -ENOMEM only when kcalloc fails
> (remove the blanket -ENOMEM at the free_mem path).
>

>> diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c
>> index f977734ae712c..7df256a9e01c5 100644
>> --- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c
>> +++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c
>> @@ -1566,13 +1567,15 @@ int rvu_mbox_handler_nix_lf_alloc(struct rvu *rvu,
>>
>>  	/* Alloc NIX RQ HW context memory and config the base */
>>  	hwctx_size = 1UL << ((ctx_cfg >> 4) & 0xF);
>> -	err = qmem_alloc(rvu->dev, &pfvf->rq_ctx, req->rq_cnt, hwctx_size);
>> -	if (err)
>> +	rc = qmem_alloc(rvu->dev, &pfvf->rq_ctx, req->rq_cnt, hwctx_size);
>> +	if (rc)
>>  		goto free_mem;
>>
>>  	pfvf->rq_bmap = kcalloc(req->rq_cnt, sizeof(long), GFP_KERNEL);
>> -	if (!pfvf->rq_bmap)
>> +	if (!pfvf->rq_bmap) {
>> +		rc = -ENOMEM;
>>  		goto free_mem;
>> +	}
>While reviewing these error handling updates, I noticed a potential
>regression in the surrounding allocation logic. Does this code leak the DMA
>memory for pfvf->rq_ctx and pfvf->rq_bmap if a Virtual Function repeatedly
>sends NIX_LF_ALLOC messages without first sending a corresponding NIX_LF_FREE?
>Since qmem_alloc and kcalloc unconditionally allocate memory and overwrite
>the existing pfvf pointers without freeing the old ones, could an unprivileged
>guest exhaust host memory by continuously triggering this mailbox handler?
>The same pattern appears to apply to pfvf->sq_ctx and pfvf->cq_ctx further
>down in the function.
The concern regarding multiple sequential allocations without an
explicit free operation is mathematically valid, but it does not represent
a realistic vector for host memory exhaustion in this path.

The NIX Logical Function (LF) provisioning handler is an administrative
mailbox message governed by the upstream Virtual Function (VF)
managed by the RVU core. A VF cannot arbitrarily invoke NIX_LF_ALLOC
repeatedly to leak memory; the resource virtualization layer tracks the
lifecycle state of each functional interface, ensuring that an LF cannot be
re-allocated if it is already in an active or allocated state.

Furthermore, introducing extensive state validation or pre-allocation checks here falls
completely outside the scope of this enhancement patch.
Since this series focuses solely on replacing uninitialized return values and
standardizing error tracking, adding complex architectural lifecycle checks
would break patch granularity. This specific lifecycle robustification is more
appropriately handled via a dedicated hardening patch in a future net-next cycle.