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

[Ratheesh Kannoth]

On 2026-05-20 at 07:39:36, 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).

>
>>  	/* 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;
>This isn't a bug introduced by this patch, but can repeated NIX_LF_ALLOC
>mailbox messages cause an unbounded memory leak of host DMA and heap memory?
>The function rvu_mbox_handler_nix_lf_alloc() handles the NIX_LF_ALLOC
>mailbox request by allocating memory for several context structures via
>qmem_alloc() and context bitmaps via kcalloc(). The pointers to these new
>allocations are written directly to the pfvf structure.
>However, there appears to be no check to ensure the contexts have not been
>allocated already, nor are existing allocations freed. Can a guest VM (VF)
>trigger this by repeatedly sending the NIX_LF_ALLOC message, constantly
>triggering new allocations while abandoning the previous pointers? This
>might leak host memory (especially dma_alloc_attrs space used in
>qmem_alloc()), potentially leading to host memory exhaustion.

The number of available NIX LFs is
structurally finite and bounded by the hardware topology. A VF/PF cannot
arbitrarily trigger allocations without successfully provisioned LF
resources. Furthermore, the NIX_LF_FREE mailbox path guarantees the
complete rollback and freeing of all hardware context memories (via
qmem_free) and bitmaps allocated during NIX_LF_ALLOC.

Repeated calls to NIX_LF_ALLOC on an already active/
allocated LF context are rejected earlier in the pipeline by validation
checks verifying block provisioning status, preventing dangling pointers or
unbounded heap leaks in nominal operation.

this patch strictly unifies the error return code
variable from 'err' to 'rc' to match driver-wide conventions. Addressing
secondary, pre-existing hardening improvements for the allocation path falls
outside the scope of this transactional fix and is better suited as a
separate hardening patch targeted at net-next.