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

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.