Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] Removing `drm_dev_get()` from `xe_pci_barrier_mmap()` causes a device reference count underflow, leading to a potential use-after-free of the `xe_device`. --
--- Patch [1]: [PATCH] drm/xe: Fix reference count leak in xe_pci_barrier_mmap() --- commit fb6604d312d887a8133909c7e0434e96c90e6a7d Author: Lu Yao <[email protected]> drm/xe: Fix reference count leak in xe_pci_barrier_mmap() This commit removes a drm_dev_get() call in xe_pci_barrier_mmap(), with the stated assumption that the vm_ops .open and .close callbacks already handle the reference counting. > diff --git a/drivers/gpu/drm/xe/xe_device.c b/drivers/gpu/drm/xe/xe_device.c > --- a/drivers/gpu/drm/xe/xe_device.c > +++ b/drivers/gpu/drm/xe/xe_device.c > @@ -341,7 +341,6 @@ static int xe_pci_barrier_mmap(struct file *filp, > vm_flags_set(vma, VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP | VM_IO); > vma->vm_ops = &vm_ops_barrier; > vma->vm_private_data = dev; > - drm_dev_get(vma->vm_private_data); [Severity: High] Will this removal lead to a device reference count underflow when the VMA is eventually closed? The memory management subsystem does not call a VMA's .open callback upon initial creation via mmap(), it is only invoked during VMA duplication like fork() or mremap(). Because the explicit drm_dev_get() is removed in xe_pci_barrier_mmap(), the initial VMA is created without incrementing the device reference count. When the VMA is unmapped, barrier_close() unconditionally drops a reference: static void barrier_close(struct vm_area_struct *vma) { drm_dev_put(vma->vm_private_data); } Does this unmatched put cause a reference count underflow and potential use-after-free of the drm_device? > > return 0; > } -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
