Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] Resource leak: `KernelBo::drop` permanently leaks the GEM buffer object and its virtual mapping if `vm.unmap_range()` fails. --
--- Patch [5]: [PATCH v10 5/7] drm/tyr: add a kernel buffer object --- commit f17ba69672f18401371cf98a1da7881e0b938c23 Author: Deborah Brouwer <[email protected]> drm/tyr: add a kernel buffer object This commit introduces a buffer object type (KernelBo) for internal driver allocations managed by the kernel. It wraps a GEM shmem object and automatically handles GPU virtual address space mapping during creation and unmapping on drop. > diff --git a/drivers/gpu/drm/tyr/gem.rs b/drivers/gpu/drm/tyr/gem.rs > index c28be61a01bb2..69e1c75e59a55 100644 > --- a/drivers/gpu/drm/tyr/gem.rs > +++ b/drivers/gpu/drm/tyr/gem.rs [ ... ] > +impl Drop for KernelBo<'_> { > + fn drop(&mut self) { > + let va = self.va_range.start; > + let size = self.va_range.end - self.va_range.start; > + > + if let Err(e) = self.vm.unmap_range(va, size) { [Severity: Medium] Does this leak the GEM buffer object if unmap_range() fails? If unmap_range() encounters an error (such as a kmalloc failure due to memory pressure when preallocating GPUVA objects to handle a mapping split), it aborts the unmap operation. Because the error is caught and ignored here, the drm_gpuvm will retain its reference to the GEM object indefinitely, leaking it along with its physical pages. > + // If unmap_range fails, it is still safe to drop the > + // KernelBo and its ARef to the GEM buffer object because > + // GPUVM also holds a reference to the GEM buffer object. > + // The physical pages won't be freed or reallocated. > + dev_err!( > + self.vm.dev(), > + "Failed to unmap KernelBo range {:#x}..{:#x}: {:?}", > + self.va_range.start, > + self.va_range.end, > + e > + ); > + } > + } > +} -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=5
