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 v15 07/10] drm/xe/pm: Introduce xe_device_suspend/resume()
Date: Thu, 12 Nov 2026 09:34:36 +0000	[thread overview]
Message-ID: <sashiko-outbox-210889@kernel.org> (raw)
In-Reply-To: <20261112091033.1813803-8-raag.jadav@intel.com>

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [High] drm/xe: unsynchronized scheduler queues in xe_device_suspend()
  FLR path
--

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

drm/xe/pm: Introduce xe_device_suspend/resume()

This commit factors out xe_device_suspend() and xe_device_resume() from
xe_pm_suspend() and xe_pm_resume(), adding an flr flag to handle PCIe FLR
preparation and re-initialization alongside system suspend and resume.

> diff --git a/drivers/gpu/drm/xe/xe_device.c b/drivers/gpu/drm/xe/xe_device.c
> index 273e2c45fea9b..6911c2ac39f82 100644
> --- a/drivers/gpu/drm/xe/xe_device.c
> +++ b/drivers/gpu/drm/xe/xe_device.c
[ ... ]
> @@ -1384,3 +1385,157 @@ void xe_device_exit(void)
>  		wait_var_event(&xe_device_count, !atomic_read(&xe_device_count));
>  	}
>  }
> +
> +/**
> + * xe_device_suspend() - Common helper for system suspend and FLR prepare
> + * @xe: xe device instance
> + * @hibernate: true if preparing for S4 hibernation, false for < S4 suspend
> + * @flr: indicate FLR prepare
> + *
> + * Return: 0 on success, negative error code otherwise.
> + */
> +int xe_device_suspend(struct xe_device *xe, bool hibernate, bool flr)
> +{
> +	struct xe_gt *gt;
> +	u8 id;
> +	int err;
> +
> +	err = xe_pxp_pm_suspend(xe->pxp);
> +	if (err)
> +		return err;
> +
> +	xe_late_bind_pm_suspend(&xe->late_bind);
> +
> +	for_each_gt(gt, xe, id)
> +		xe_gt_suspend_prepare(gt);
> +
> +	if (flr) {
> +		for_each_gt(gt, xe, id)
> +			xe_gt_flr_prepare(gt);

[Severity: High]
Can xe_gt_flr_prepare() -> xe_uc_flr_prepare() race with
sched->base.submit_wq when aborting in-flight GuC jobs during FLR, causing
either an infinite zero-delay work_tdr livelock on gt->ordered_wq or a
failed drm_sched_is_stopped() assertion in xe_sched_reinit() on resume?

xe_uc_flr_prepare() queues and flushes uc_flr_prepare() on gt->ordered_wq,
and immediately queues and flushes uc_flr_sanitize() on the same
gt->ordered_wq:

drivers/gpu/drm/xe/xe_uc.c:xe_uc_flr_prepare() {
    ...
	INIT_WORK_ONSTACK(&flr.work, uc_flr_prepare);
	queue_work(gt->ordered_wq, &flr.work);
	flush_work(&flr.work);
	destroy_work_on_stack(&flr.work);

	INIT_WORK_ONSTACK(&flr.work, uc_flr_sanitize);
	queue_work(gt->ordered_wq, &flr.work);
	flush_work(&flr.work);
	destroy_work_on_stack(&flr.work);
}

uc_flr_prepare() calls xe_guc_submit_pause_abort(), which starts scheduler
submission (queuing work_run_job and work_free_job on sched->base.submit_wq,
a separate workqueue from gt->ordered_wq) and kills each queue via
xe_sched_tdr_queue_imm(), setting sched->base.timeout = 0 and queuing
work_tdr with delay 0 on gt->ordered_wq:

gt->ordered_wq                    sched->base.submit_wq
--------------                    ---------------------
uc_flr_prepare()
  xe_guc_submit_pause_abort()
    xe_sched_submission_start()
    guc_exec_queue_kill()
      xe_sched_tdr_queue_imm()
        sched->base.timeout = 0
        queue work_tdr (delay 0)
drm_sched_job_timedout()
  guc_exec_queue_timedout_job()
    dma_fence_set_error(-ETIME)
    return DRM_GPU_SCHED_STAT_NO_HANG
  drm_sched_job_reinsert_on_false_timeout()
    list_add(&job->list, &pending_list)
    queue work_free_job --------->
  drm_sched_start_timeout_unlocked()
    queue work_tdr (delay 0)
uc_flr_sanitize()
  xe_guc_stop()
    drm_sched_wqueue_stop()
      sched->base.pause_submit = true
      cancel_work_sync(&work_free_job)
                                  (work_free_job cancelled before running)
drm_sched_job_timedout()
  guc_exec_queue_timedout_job()
    (fence already signaled, returns NO_HANG)
  drm_sched_job_reinsert_on_false_timeout()
    (drm_sched_is_stopped() is true, work_free_job not queued)
  drm_sched_start_timeout_unlocked()
    queue work_tdr (delay 0)      <-- infinite livelock on gt->ordered_wq

Conversely, if a job was still queued in entity->job_queue when
uc_flr_prepare() ran, work_run_job on sched->base.submit_wq can pop it into
pending_list and queue work_tdr on gt->ordered_wq behind uc_flr_sanitize().
After uc_flr_sanitize() stops the scheduler, work_tdr runs
guc_exec_queue_timedout_job(), which calls xe_sched_submission_start() and
leaves pause_submit false, tripping
xe_gt_assert(ge->q->gt, drm_sched_is_stopped(&sched->base)) in
xe_sched_reinit() during xe_device_resume(xe, true).

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

  reply	other threads:[~2026-11-12  9:34 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-12  9:09 [PATCH v15 00/10] Introduce Xe PCIe FLR Raag Jadav
2026-11-12  9:09 ` [PATCH v15 01/10] drm/xe/uc_fw: Allow re-initializing firmware Raag Jadav
2026-11-12  9:09 ` [PATCH v15 02/10] drm/xe/guc_submit: Introduce guc_exec_queue_reinit_kernel() Raag Jadav
2026-11-12  9:09 ` [PATCH v15 03/10] drm/xe/gt: Introduce FLR helpers Raag Jadav
2026-11-12  9:45   ` sashiko-bot
2026-11-12  9:09 ` [PATCH v15 04/10] drm/xe/bo_evict: Introduce xe_bo_restore_map() Raag Jadav
2026-11-12  9:09 ` [PATCH v15 05/10] drm/xe/exec_queue: Introduce xe_exec_queue_reinit() Raag Jadav
2026-11-12  9:09 ` [PATCH v15 06/10] drm/xe/migrate: Introduce xe_migrate_reinit() and xe_cpu_bind_reinit() Raag Jadav
2026-11-12  9:43   ` sashiko-bot
2026-11-12  9:09 ` [PATCH v15 07/10] drm/xe/pm: Introduce xe_device_suspend/resume() Raag Jadav
2026-11-12  9:34   ` sashiko-bot [this message]
2026-11-12  9:09 ` [PATCH v15 08/10] drm/xe: Introduce temporary device wedging Raag Jadav
2026-11-12  9:09 ` [PATCH v15 09/10] drm/xe/pci: Introduce PCIe Function Level Reset Raag Jadav
2026-11-12 10:02   ` sashiko-bot
2026-11-12  9:09 ` [PATCH v15 10/10] drm/xe/doc: Wire up PCI Error Handling Raag Jadav
2026-11-12  9:18 ` ✗ CI.checkpatch: warning for Introduce Xe PCIe FLR (rev15) Patchwork
2026-11-12  9:20 ` ✓ CI.KUnit: success " Patchwork
2026-11-12  9:57 ` ✓ Xe.CI.BAT: " Patchwork
2026-11-12 15:22 ` ✓ 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=sashiko-outbox-210889@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.