Re: [PATCH] drm/xe/tlb_inval: Squash wedged error in GGTT TLB invalidation

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Incomplete fix for -ENOTRECOVERABLE during TLB invalidation on wedged devices, leaving PPGTT and ALL invalidation paths unfixed.
--

commit aa259f67109f1c7c63d45a7dc6b510e56c304328
Author: Shuicheng Lin <shuicheng.lin@intel.com>

drm/xe/tlb_inval: Squash wedged error in GGTT TLB invalidation

This commit squashes -ENOTRECOVERABLE into -ECANCELED during GGTT TLB
invalidation on wedged devices. It avoids a WARN_ON taint during resets.

> diff --git a/drivers/gpu/drm/xe/xe_guc_tlb_inval.c b/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> index 111fef781b2ab..578cafa5526dd 100644
> --- a/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> +++ b/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> @@ -75,8 +75,14 @@ static int send_tlb_inval_ggtt(struct xe_tlb_inval *tlb_inval, u32 seqno)
>  			seqno,
>  			MAKE_INVAL_OP(XE_GUC_TLB_INVAL_GUC),
>  		};
> +		int ret;
>  
> -		return send_tlb_inval(guc, action, ARRAY_SIZE(action));
> +		ret = send_tlb_inval(guc, action, ARRAY_SIZE(action));
> +		/* Device wedged: message not delivered */
> +		if (ret == -ENOTRECOVERABLE)
> +			return -ECANCELED;
> +
> +		return ret;
>  	} else if (xe_device_uc_enabled(xe) && !xe_device_wedged(xe)) {
>  		struct xe_mmio *mmio = &gt->mmio;
>  

[Severity: High]
This isn't a bug introduced by this patch, but does this incomplete fix leave
other invalidation paths vulnerable to the same -ENOTRECOVERABLE propagation?

For instance, in send_tlb_inval_ppgtt(), send_tlb_inval() can return
-ENOTRECOVERABLE unmodified when the device is wedged:

drivers/gpu/drm/xe/xe_guc_tlb_inval.c:send_tlb_inval_ppgtt() {
	...
	err = send_tlb_inval(guc, action, len);
	if (!err && prl_sa) {
		xe_gt_assert(gt, seqno != TLB_INVALIDATION_SEQNO_INVALID);
		err = send_page_reclaim(guc, seqno, xe_sa_bo_gpu_addr(prl_sa));
	}
	return err;
}

If a PPGTT invalidation occurs on a wedged device (e.g., during VMA teardown or
BO eviction), it propagates -ENOTRECOVERABLE up the stack.

This triggers a WARN_ON_ONCE in xe_svm_range_notifier_event():

drivers/gpu/drm/xe/xe_svm.c:xe_svm_range_notifier_event() {
	...
	err = xe_tlb_inval_range_tilemask_submit(xe, vm->usm.asid, adj_start,
						 adj_end, tile_mask, &batch);
	if (!WARN_ON_ONCE(err))
		xe_tlb_inval_batch_wait(&batch);
	...
}

This can abort the BO eviction or SVM teardown process, leading to resource
leaks exactly as it did in the GGTT path.

Are similar squashing checks needed in send_tlb_inval_ppgtt(),
send_tlb_inval_ctx_ppgtt(), and send_tlb_inval_all() since they also directly
return the result of send_tlb_inval() on their respective paths?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260910232734.93054-1-shuicheng.lin@intel.com?part=1