Re: [PATCH 6/6] accel/qaic: Use reduced size allocation for FIFOs

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] accel/qaic: job credits can exceed DRM scheduler credit limit
- [Medium] accel/qaic: missing __GFP_NOWARN in fallback allocation causes log spam
--

commit 71c6cfc1950c4572f2fdf94ea37059d815f2f378
Author: Carl Vanderlip <carl.vanderlip@oss.qualcomm.com>
Subject: accel/qaic: Use reduced size allocation for FIFOs

This commit modifies the allocation strategy for FIFOs in the qaic driver.
Instead of failing when a large DMA coherent pool allocation cannot be
fulfilled, it iteratively halves the requested size until the allocation
succeeds, allowing the DRM scheduler to break up submissions to fit available
memory.

[Severity: Medium]
In drivers/accel/qaic/qaic_control.c inside encode_activate around line 663,
there is a fallback allocation loop that calls dma_alloc_coherent with
GFP_KERNEL. Because the loop starts with a large allocation size and expects
it to potentially fail on fragmented systems before halving the size, will
this cause the page allocator to print stack traces and spam dmesg on each
expected failure?

Could the __GFP_NOWARN flag be added to the allocation request to prevent
this log spam when the higher order allocations predictably fail?

[Severity: High]
In drivers/accel/qaic/qaic_control.c inside encode_activate around line 671,
nelem is calculated based on the dynamically reduced size using the
QAIC_DBC_NELEM macro. This can result in a non-power-of-two queue size.

Later, in drivers/accel/qaic/qaic_sched.c inside set_dbc_scaling_ratio at
line 98, the credit_ratio is computed using DIV_ROUND_UP(QAIC_CREDITS, nelem).

If nelem is not a power of two, the rounding up means that a job requesting
the maximum number of elements in qaic_create_job (around line 156) will
calculate its total credits as (nelem - 1) multiplied by credit_ratio. Can
this total routinely exceed the QAIC_CREDITS limit and the DRM scheduler
maximum credit limit?

If a user submits a large execution request that triggers this, it appears
it would result in a dev_WARN and credit truncation within the DRM scheduler,
preventing the job from executing properly. How should this credit overflow
be prevented when dealing with non-power-of-two sizes?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261003023818.1161666-1-carl.vanderlip@oss.qualcomm.com?part=6