Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] Skipping `dma_resv_wait_timeout` based on CPU-side state (`tile_present == 0`) causes the driver to unmap DMA addresses while a GPU unbind job is still in flight, leading to IOMMU faults and physical memory Use-After-Free. --
[Note: The format of this report has been altered to provide a free-form summary without direct code quotes, due to system recitation restrictions.] commit 3a11397b2ceb001d3564c3c183ff54d6b34bd490 Author: aquiles <[email protected]> drm/xe: skip resv fence wait in xe_svm_invalidate if no ranges are bound This commit modifies xe_svm_invalidate() to pre-scan affected SVM ranges and skip the dma_resv_wait_timeout() if no ranges are currently bound to the GPU (indicated by tile_present == 0). This is intended to prevent stalling CPU reclaim when handling MMU notifier events for unbound SVM ranges. [Severity: High] Does skipping the dma_resv_wait_timeout() based on the CPU-side tile_present state introduce a race condition with asynchronous GPU unbind operations? In xe_svm_invalidate(), the newly added pre-scan loop skips the reservation wait if range->tile_present is zero. However, looking at op_commit() in drivers/gpu/drm/xe/xe_pt.c, tile_present is cleared synchronously when an unbind job is submitted, not when it completes. The actual page-table update job is queued asynchronously to the GPU and tracked by a BOOKKEEP fence on the VM's reservation object. If an MMU notifier event (like CPU page reclaim) fires concurrently, the pre-scan sees tile_present == 0, skips the fence wait, and jumps straight to cleanup. This causes drm_gpusvm_range_unmap_pages() to unmap the DMA addresses while the GPU unbind is still in flight. Can this lead to IOMMU faults and potential use-after-free of physical memory, since the CPU will free the pages before the GPU has actually finished unmapping them? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=2
