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 <[email protected]> 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/[email protected]?part=6
