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 v6 1/7] drm/xe/gt: Use GT ordered workqueue for wedging
Date: Wed, 14 Oct 2026 06:14:55 +0000	[thread overview]
Message-ID: <sashiko-outbox-170856@kernel.org> (raw)
In-Reply-To: <20261014055215.330408-2-raag.jadav@intel.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] drm/xe: Infinite TDR loop when device wedged during GT init
--

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

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

This commit introduces a worker for GT specific wedge handling and queues the
teardown on the GT ordered workqueue. This prevents scheduler disruptions
while jobs are still in-flight. It also introduces the
for_each_initialized_gt() macro and uses it when declaring the device
wedged.

> diff --git a/drivers/gpu/drm/xe/xe_device.c b/drivers/gpu/drm/xe/xe_device.c
> index e1979bbcf7bc6..014bc5b0216dd 100644
> --- a/drivers/gpu/drm/xe/xe_device.c
> +++ b/drivers/gpu/drm/xe/xe_device.c
> @@ -1425,7 +1425,7 @@ void xe_device_declare_wedged(struct xe_device *xe)
>  			    WEDGED_URL, XE_BUG_URL);
>  	}
>  
> -	for_each_gt(gt, xe, id)
> +	for_each_initialized_gt(gt, xe, id)
>  		xe_gt_declare_wedged(gt);

[Severity: High]
Does this create a race condition if the device is wedged concurrently with
xe_gt_init()?

If xe_device_declare_wedged() runs while a GT is initializing, the GT is
skipped here because gt->initialized is false.

> diff --git a/drivers/gpu/drm/xe/xe_gt.c b/drivers/gpu/drm/xe/xe_gt.c
> index 775c826b68b42..d8bf538ceafff 100644
> --- a/drivers/gpu/drm/xe/xe_gt.c
> +++ b/drivers/gpu/drm/xe/xe_gt.c
[ ... ]
> @@ -769,6 +773,8 @@ int xe_gt_init(struct xe_gt *gt)
>  			return err;
>  	}
>  
> +	/* Must be last */
> +	WRITE_ONCE(gt->initialized, true);
>  	return 0;
>  }

Then xe_gt_init() sets gt->initialized to true without checking if a global
wedge event occurred during initialization.

This allows the GT to become active even though its GuC was never wedged
(since xe_guc_submit_wedge() was skipped during xe_device_declare_wedged()).

If jobs submitted to this GT (like migration jobs) hang, the TDR in
guc_exec_queue_timedout_job() runs. Since the TDR detects the global wedge
via xe_wedged(), it skips the hardware reset but returns NO_HANG while
immediately re-queueing the TDR work:

drivers/gpu/drm/xe/xe_guc_submit.c:guc_exec_queue_timedout_job() {
    ...
    xe_guc_exec_queue_trigger_cleanup(q);

    if (wedge_device)
        xe_device_declare_wedged(gt_to_xe(q->gt));

    /*
     * We want the job added back to the pending list so it gets freed; this
     * is what DRM_GPU_SCHED_STAT_NO_HANG does.
     */
    return DRM_GPU_SCHED_STAT_NO_HANG;
}

Can this lead to an infinite TDR spinloop (100% CPU deadlock) since the job
is never completed nor is the hardware reset?

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

  reply	other threads:[~2026-10-14  6:15 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-14  5:51 [PATCH v6 0/7] Introduce xe_wedge Raag Jadav
2026-10-14  5:51 ` [PATCH v6 1/7] drm/xe/gt: Use GT ordered workqueue for wedging Raag Jadav
2026-10-14  6:14   ` sashiko-bot [this message]
2026-10-14  5:51 ` [PATCH v6 2/7] drm/xe: Drop xe_device_set_wedged_method() Raag Jadav
2026-10-14  5:51 ` [PATCH v6 3/7] drm/xe: Move xe_device_wedged_fini() registration to xe_device_probe_early() Raag Jadav
2026-10-14  5:51 ` [PATCH v6 4/7] drm/xe: Make xe_device_declare_wedged() IRQ safe Raag Jadav
2026-10-14  6:13   ` sashiko-bot
2026-10-14  5:51 ` [PATCH v6 5/7] drm/xe/pci_error: Flush GT wedge worker before bus reset Raag Jadav
2026-10-14  5:51 ` [PATCH v6 6/7] drm/xe: Introduce xe_wedge Raag Jadav
2026-10-14  6:05   ` sashiko-bot
2026-10-14  5:51 ` [PATCH v6 7/7] drm/xe/ras: Move xe_ras_process_errors() to xe_ras Raag Jadav
2026-10-14  6:14   ` sashiko-bot
2026-10-14  5:59 ` ✗ CI.checkpatch: warning for Introduce xe_wedge (rev5) Patchwork
2026-10-14  6:02 ` ✓ CI.KUnit: success " Patchwork
2026-10-14 11:33 ` ✓ Xe.CI.BAT: " 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-170856@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.