Re: [PATCH v2 13/33] drm/xe: Flush L2 asynchronously in xe_bo_trigger_rebind()

[sashiko-bot@kernel.org]

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 <matthew.brost@intel.com>

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, &gt->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/20260710215442.2444235-1-matthew.brost@intel.com?part=13