Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] GFP_KERNEL allocation in shrinker and dma-resv critical section causes deadlocks and lockdep splats --
--- Patch [13]: [PATCH v2 13/33] drm/xe: Flush L2 asynchronously in xe_bo_trigger_rebind() --- commit 985db7b22213ce9503872b19a27fddeba9fe24ff Author: Matthew Brost <[email protected]> drm/xe: Flush L2 asynchronously in xe_bo_trigger_rebind() This commit replaces synchronous TLB invalidations during buffer object eviction with asynchronous flushes on L2-flush-optimized hardware. It queues a TLB invalidation job per VMA, which waits on the buffer's in-flight GPU work before flushing. > diff --git a/drivers/gpu/drm/xe/xe_bo.c b/drivers/gpu/drm/xe/xe_bo.c > --- a/drivers/gpu/drm/xe/xe_bo.c > +++ b/drivers/gpu/drm/xe/xe_bo.c [ ... ] > @@ -732,6 +732,13 @@ static int xe_bo_trigger_rebind(struct xe_device *xe, > struct xe_bo *bo, > */ > if (!xe_device_is_l2_flush_optimized(xe)) > continue; > + > + /* > + * Attempt to flush L2 async, fallback to sync flush on > + * failure > + */ > + if (!xe_vm_flush_vm_bo_tlb_async(vm, bo, vm_bo)) > + continue; [Severity: High] Does this create a deadlock regression when reached from the shrinker path? The memory shrinker can call into this path through xe_shrinker_scan() -> xe_bo_shrink() -> xe_bo_move_notify() -> xe_bo_trigger_rebind(). In this path, the shrinker operates under the fs_reclaim pseudo-lock and holds the buffer object's dma-resv lock. > diff --git a/drivers/gpu/drm/xe/xe_vm.c b/drivers/gpu/drm/xe/xe_vm.c > --- a/drivers/gpu/drm/xe/xe_vm.c > +++ b/drivers/gpu/drm/xe/xe_vm.c [ ... ] > +static int xe_vma_tlb_flush_client(struct xe_vm *vm, struct xe_vma *vma, > + struct xe_tile *tile, struct xe_gt *gt, > + struct dma_resv *resv, struct dma_fence *dep, > + int type) > +{ > + struct xe_exec_queue *q = xe_migrate_exec_queue(tile->migrate); > + struct xe_tlb_inval_job *job; > + struct dma_fence *fence; > + int err; > + > + job = xe_tlb_inval_job_create(q, >->tlb_inval, > + q->tlb_inval[type].dep_scheduler, vm, > + xe_vma_start(vma), xe_vma_end(vma), type); [Severity: High] Could this allocation recurse into memory reclaim and attempt to acquire the same dma-resv lock, or trigger a lockdep splat for context violations? The xe_tlb_inval_job_create() function allocates the job using a default GFP_KERNEL allocation. Furthermore, the subsequent call to xe_tlb_inval_job_alloc_dep() explicitly calls might_alloc(GFP_KERNEL). Since this can be reached while holding the dma-resv lock or while in the shrinker reclaim path, these GFP_KERNEL allocations appear to violate the context constraints. -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=13
