Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] Missing mmput() on memory allocation failure causes mm_struct leak. -- --- Patch [4]: [PATCH v2 4/4] fixup! drm/gpusvm: use hmm_range_fault_unlocked_timeout() for range faults --- commit ece4b74fbf695a6f71fbfd09dfe6eb481688809b Author: Stanislav Kinsburskii <[email protected]> fixup! drm/gpusvm: use hmm_range_fault_unlocked_timeout() for range faults This commit updates the timeout handling for hmm_range_fault_unlocked_timeout() by passing the HMM_RANGE_DEFAULT_TIMEOUT directly instead of calculating an absolute deadline. This keeps the timeout focused on repeated notifier retries inside HMM. > diff --git a/drivers/gpu/drm/drm_gpusvm.c b/drivers/gpu/drm/drm_gpusvm.c > index b8f2dd9982f53..76e8a0028c7fc 100644 > --- a/drivers/gpu/drm/drm_gpusvm.c > +++ b/drivers/gpu/drm/drm_gpusvm.c [ ... ] > @@ -1734,8 +1726,7 @@ int drm_gpusvm_range_evict(struct drm_gpusvm *gpusvm, > return -ENOMEM; [Severity: High] This is a pre-existing issue, but does this error path leak the mm_struct reference? Looking at drm_gpusvm_range_evict(), if kvmalloc_array() fails to allocate the pfns array, it returns -ENOMEM directly without dropping the reference acquired earlier via mmget_not_zero(): int drm_gpusvm_range_evict(struct drm_gpusvm *gpusvm, struct drm_gpusvm_range *range) { ... if (!mmget_not_zero(mm)) return -EFAULT; pfns = kvmalloc_array(npages, sizeof(*pfns), GFP_KERNEL); if (!pfns) return -ENOMEM; ... } Can this permanently pin the process address space if an unprivileged userspace application creates a massive GPU SVM range that causes the allocation to fail? > > hmm_range.hmm_pfns = pfns; > - err = hmm_range_fault_unlocked_timeout(&hmm_range, > - max_t(long, timeout - jiffies, 1)); > + err = hmm_range_fault_unlocked_timeout(&hmm_range, timeout); > > kvfree(pfns); > mmput(mm); -- Sashiko AI review ยท https://sashiko.dev/#/patchset/178406760622.1106335.2379450382728057793.stgit@skinsburskii?part=4
