Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] Missing newline in debugfs output for buffer objects without fences. --
commit 642a225a01d32a7d60ac3ca80f3eb6f52693b3f4 Author: Michał Mirosław <[email protected]> drm/amdgpu: debugfs: avoid extra EOLs in amdgpu_gem_info This commit aims to avoid printing extra newlines in the amdgpu_gem_info debugfs output. It does this by moving the newline into the lock failure path when attempting to dump buffer object fences. > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c > @@ -1696,8 +1696,9 @@ u64 amdgpu_bo_print_info(int id, struct amdgpu_bo *bo, > struct seq_file *m) > if (dma_resv_trylock(bo->tbo.base.resv)) { > dma_resv_describe(bo->tbo.base.resv, m); > dma_resv_unlock(bo->tbo.base.resv); > + } else { > + seq_puts(m, "\n"); > } > - seq_puts(m, "\n"); > > return size; > } [Severity: Medium] Will this cause garbled debugfs output for buffer objects that do not have any fences attached? When dma_resv_trylock() succeeds, amdgpu_bo_print_info() calls dma_resv_describe(). Looking at dma_resv_describe() in drivers/dma-buf/dma-resv.c: void dma_resv_describe(struct dma_resv *obj, struct seq_file *seq) { ... dma_resv_for_each_fence(&cursor, obj, DMA_RESV_USAGE_READ, fence) { seq_printf(seq, "\t%s fence:", ...); dma_fence_describe(fence, seq); } } If there are no fences, dma_resv_describe() iterates zero times and prints nothing. Because the unconditional newline was moved to the lock-failure branch, the success path for a fenceless buffer object now prints nothing at all. This means the next item dumped in the debugfs file will be concatenated onto the same line, breaking readability and parsing tools. Should a newline still be printed when the lock succeeds but no fences are present? -- Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=5
