All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Matthew Brost" <matthew.brost@intel.com>
Cc: intel-xe@lists.freedesktop.org
Subject: Re: [PATCH v2] drm/xe: Add mnemonic error reason to page fault diagnostics
Date: Thu, 17 Sep 2026 19:48:57 +0000	[thread overview]
Message-ID: <20260917194858.1958F1F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260917193815.209362-1-matthew.brost@intel.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] drm/xe: stale pagefault error codes mask true failure reasons on retries
--

commit 316fc8037f7fbbec7bf65ce4fb4107de7eac1d79
Author: Matthew Brost <matthew.brost@intel.com>
drm/xe: Add mnemonic error reason to page fault diagnostics

This patch adds enum xe_pagefault_error to encode failure reasons into the
reserved low bits of the page address. This allows xe_pagefault_print to
report a mnemonic failure reason.

> diff --git a/drivers/gpu/drm/xe/xe_pagefault.c b/drivers/gpu/drm/xe/xe_pagefault.c
> --- a/drivers/gpu/drm/xe/xe_pagefault.c
> +++ b/drivers/gpu/drm/xe/xe_pagefault.c

[ ... ]

> @@ -195,8 +203,10 @@ static int xe_pagefault_handle_vma(struct xe_gt *gt, struct xe_vma *vma,
>  						 needs_vram == 1);
>  			drm_exec_retry_on_contention(&exec);
>  			xe_validation_retry_on_oom(&ctx, &err);
> -			if (err)
> +			if (err) {
> +				xe_pagefault_set_error(pf, XE_PAGEFAULT_ERROR_VMA_VALIDATE);
>  				break;
> +			}

[Severity: Medium]
Does this leak the error state into subsequent retries if the failure is a
transient -EAGAIN?

If a transient failure occurs, xe_pagefault_set_error sets
XE_PAGEFAULT_ERROR_VMA_VALIDATE. When the outer loop retries, this error code
remains attached to pf. If a later retry fails for a different reason, the
stale error code might mask the true failure reason.

[ ... ]

> diff --git a/drivers/gpu/drm/xe/xe_svm.c b/drivers/gpu/drm/xe/xe_svm.c
> --- a/drivers/gpu/drm/xe/xe_svm.c
> +++ b/drivers/gpu/drm/xe/xe_svm.c

[ ... ]

> @@ -1480,11 +1488,15 @@ int xe_svm_handle_pagefault(struct xe_vm *vm, struct xe_vma *vma,
>  		 * may have been split by xe_svm_range_set_default_attr.
>  		 */
>  		vma = xe_vm_find_vma_by_addr(vm, fault_addr);
> -		if (!vma)
> +		if (!vma) {
> +			xe_pagefault_set_error(pf, XE_PAGEFAULT_ERROR_SVM_VMA_NOT_FOUND);
>  			return -EINVAL;
> +		}
>  
>  		goto retry;
>  	}
> +	if (ret && xe_pagefault_get_error(pf) == XE_PAGEFAULT_ERROR_NONE)
> +		xe_pagefault_set_error(pf, XE_PAGEFAULT_ERROR_SVM_SERVICE_FAILED);
>  	return ret;
>  }

[Severity: Medium]
Can a previous transient error mask the true failure reason here?

For example, if __xe_svm_handle_pagefault encounters a transient -EAGAIN
failure during xe_svm_garbage_collector, it sets
XE_PAGEFAULT_ERROR_SVM_GARBAGE_COLLECTOR.

When the retry happens, if it subsequently fails at a different point (such
as getting pages) that relies on this fallback error assignment, the
condition evaluates to false because the error state is no longer
XE_PAGEFAULT_ERROR_NONE.

Would it be safer to clear the error state before retrying, or
unconditionally overwrite the fallback error here?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260917193815.209362-1-matthew.brost@intel.com?part=1

  reply	other threads:[~2026-09-17 19:49 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-17 19:38 [PATCH v2] drm/xe: Add mnemonic error reason to page fault diagnostics Matthew Brost
2026-09-17 19:48 ` sashiko-bot [this message]
2026-09-17 20:43 ` ✓ CI.KUnit: success for drm/xe: Add mnemonic error reason to page fault diagnostics (rev2) Patchwork
2026-09-17 21:36 ` ✓ Xe.CI.BAT: " Patchwork
2026-09-18  0:43 ` ✓ Xe.CI.FULL: " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260917194858.1958F1F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=matthew.brost@intel.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.