All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Raag Jadav" <raag.jadav@intel.com>, intel-xe@lists.freedesktop.org
Subject: Re: [PATCH v10 1/9] drm/xe/gt: Use GT ordered workqueue for wedging
Date: Fri, 16 Oct 2026 07:50:03 +0000	[thread overview]
Message-ID: <sashiko-outbox-173970@kernel.org> (raw)
In-Reply-To: <20261016072623.457392-2-raag.jadav@intel.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] drm/xe: gt_wedge_worker assertion fails if device is suspended
--

commit ad400bddb33c2efaf9ed050aad03a83745b08aa2
Author: Raag Jadav <raag.jadav@intel.com>

drm/xe/gt: Use GT ordered workqueue for wedging

This commit introduces a GT wedge worker to handle execution queue
teardown asynchronously, avoiding scheduler disruption while jobs are
in-flight. It also adds a for_each_initialized_gt() macro to prevent
races if the device is wedged during the probe sequence.

> diff --git a/drivers/gpu/drm/xe/xe_gt.c b/drivers/gpu/drm/xe/xe_gt.c
> index bc9bf6f0b5a79..27f32627a1f9b 100644
> --- a/drivers/gpu/drm/xe/xe_gt.c
> +++ b/drivers/gpu/drm/xe/xe_gt.c
[ ... ]
> @@ -1204,6 +1209,15 @@ struct xe_hw_engine *xe_gt_any_hw_engine(struct xe_gt *gt)
>  	return NULL;
>  }
>  
> +static void gt_wedge_worker(struct work_struct *w)
> +{
> +	struct xe_gt *gt = container_of(w, typeof(*gt), wedge.worker);
> +
> +	xe_device_assert_mem_access(gt_to_xe(gt));

[Severity: High]
Does this assertion fail if the device is suspended?

If a hardware fault or PCIe AER injection triggers wedging while the
device is in a runtime-suspended state (like D3hot), the error handler
calls xe_device_declare_wedged() in drivers/gpu/drm/xe/xe_device.c.

That function uses xe_pm_runtime_get_noresume():

	if (!atomic_xchg(&xe->wedged.flag, 1)) {
		xe->needs_flr_on_fini = true;
		xe_pm_runtime_get_noresume(xe);

This increments the PM usage count but leaves the device suspended.

When this asynchronous gt_wedge_worker executes, it unconditionally hits
xe_device_assert_mem_access(). Since the device is still
runtime-suspended, this assertion will fail, potentially causing a kernel
warning that disrupts the recovery process.

> +	xe_uc_declare_wedged(&gt->uc);
> +	xe_tlb_inval_reset(&gt->tlb_inval);
> +}
> +

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261016072623.457392-1-raag.jadav@intel.com?part=1

  reply	other threads:[~2026-10-16  7:50 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-16  7:25 [PATCH v10 0/9] Introduce xe_wedge Raag Jadav
2026-10-16  7:25 ` [PATCH v10 1/9] drm/xe/gt: Use GT ordered workqueue for wedging Raag Jadav
2026-10-16  7:50   ` sashiko-bot [this message]
2026-10-16  7:25 ` [PATCH v10 2/9] drm/xe: Drop xe_device_set_wedged_method() Raag Jadav
2026-10-16  7:25 ` [PATCH v10 3/9] drm/xe/hw_error: Guard csc_hw_error_work() with runtime PM Raag Jadav
2026-10-16  7:43   ` sashiko-bot
2026-10-16  7:25 ` [PATCH v10 4/9] drm/xe: Move xe_device_wedged_fini() registration to xe_device_probe_early() Raag Jadav
2026-10-16  7:25 ` [PATCH v10 5/9] drm/xe: Make xe_device_declare_wedged() IRQ safe Raag Jadav
2026-10-16  7:26 ` [PATCH v10 6/9] drm/xe/pci_error: Flush GT wedge worker before bus reset Raag Jadav
2026-10-16  7:44   ` sashiko-bot
2026-10-16  7:26 ` [PATCH v10 7/9] drm/xe/amc: Guard xe_amc_work() with runtime PM Raag Jadav
2026-10-16  7:36   ` sashiko-bot
2026-10-16  7:26 ` [PATCH v10 8/9] drm/xe: Introduce xe_wedge Raag Jadav
2026-10-16  7:34   ` sashiko-bot
2026-10-16  7:26 ` [PATCH v10 9/9] drm/xe/ras: Move xe_ras_process_errors() to xe_ras Raag Jadav
2026-10-16  7:52   ` sashiko-bot
2026-10-16  8:05 ` ✗ CI.checkpatch: warning for Introduce xe_wedge (rev9) Patchwork
2026-10-16  8:06 ` ✗ CI.KUnit: failure " 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=sashiko-outbox-173970@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=raag.jadav@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.