Re: [PATCH net] octeontx2-af: Fix memory scaling limitation in SR-IOV mode

[Ratheesh Kannoth <rkannoth@marvell.com>]

On 2026-09-20 at 06:03:24, netdev-bot+sashiko@kernel.org (netdev-bot+sashiko@kernel.org) wrote:
> Thank you for your contribution! Sashiko AI review found 3 potential
> issue(s) to consider.
>
> Critical: 0 · High: 2 (1) · Medium: 1 (1) · Low: 0 (1)
>
> If you believe none of the issues are legitimate, please reply to each
> issue of Medium severity or higher and explain why the AI is wrong.
> If any of them are legitimate and you plan to respin, please let patchwork
> know by including "pw-bot: cr" as a separate line at the end of your reply
> (one such reply per series is enough).
>
> - [High] New hard allocation ceiling in qmem_alloc() rejects the very SR-
>   IOV/mailbox allocations the commit claims to fix.
Targets CMA exhaustion from many allocations, not max single-chunk size;
supported CN20K configs remain below the boundary.

> - [High] Long-lived CPU/device-shared hardware rings and contexts are
>   converted from coherent DMA memory to an unsynchronized streaming…
OcteonTX2 is fully DMA-coherent

> - [Medium] net: octeontx2: fragile high-order buddy allocations replace
>   CMA
Deliberate move off shared CMA; CN20K mailbox HW needs physically contiguous memory,
so noncontiguous DMA APIs are not applicable; production failure mode was CMA depletion,
not buddy fragmentation.
>
> Pre-existing issues:
> - [High] Untrusted mailbox queue counts overflow the signed size
>   computation in qmem_alloc() and bypass the newly added order check,…
> - [Medium] `struct qmem.base` is produced by qmem_alloc() as a CPU
>   virtual address (previously dma_alloc_attrs(), now kzalloc()), but the…
> - [Low] qmem_alloc() publishes the devm-allocated descriptor into *q
>   (af/common.h:87-90) before both failure returns: the newly added `if…
Will address pre-existing issues in seperate followup patch.