From: sashiko-bot@kernel.org
To: "Satyanarayana K V P" <satyanarayana.k.v.p@intel.com>
Cc: intel-xe@lists.freedesktop.org
Subject: Re: [PATCH v5 2/3] drm/xe/guc: Protect timeout handling from device unplug
Date: Mon, 12 Oct 2026 06:00:53 +0000 [thread overview]
Message-ID: <sashiko-outbox-167695@kernel.org> (raw)
In-Reply-To: <20261012055053.964468-7-satyanarayana.k.v.p@intel.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] drm/scheduler: Memory leak of timed-out job when returning ENODEV
--
commit 17e9fcf9241e0bec8edf4a488366f62c46a0e6dc
Author: Satyanarayana K V P <satyanarayana.k.v.p@intel.com>
drm/xe/guc: Protect timeout handling from device unplug
This commit guards the GuC scheduler timeout callback with drm_dev_enter()
and drm_dev_exit() to handle concurrent device unplug. If an unplug has
started, it marks the job with -ENODEV and returns a corresponding status
to the scheduler.
> diff --git a/drivers/gpu/drm/xe/xe_guc_submit.c b/drivers/gpu/drm/xe/xe_guc_submit.c
> index 7ce73489c35fc..082c94340b41d 100644
> --- a/drivers/gpu/drm/xe/xe_guc_submit.c
> +++ b/drivers/gpu/drm/xe/xe_guc_submit.c
> @@ -1599,6 +1599,12 @@ guc_exec_queue_timedout_job(struct drm_sched_job *drm_job)
> int err = -ETIME;
> pid_t pid = -1;
> bool wedged = false, wedge_device = false, skip_timeout_check;
> + int idx;
> +
> + if (!drm_dev_enter(&xe->drm, &idx)) {
> + xe_sched_job_set_error(job, -ENODEV);
> + return DRM_GPU_SCHED_STAT_ENODEV;
[Severity: Medium]
Does returning DRM_GPU_SCHED_STAT_ENODEV here cause a memory leak of the
struct xe_sched_job and its associated resources?
When a job times out concurrently with device unplug, the DRM scheduler core
in drm_sched_job_timedout() explicitly drops the job from its pending list
before invoking this backend timeout callback. It only reinserts the job into
the pending list if the callback returns DRM_GPU_SCHED_STAT_NO_HANG.
By returning DRM_GPU_SCHED_STAT_ENODEV, the job remains unlinked. Even though
the fence is signaled via xe_sched_job_set_error(), the scheduler's cleanup
worker (drm_sched_free_job_work()) and teardown sequences only search
sched->pending_list.
Because the job is neither manually freed in this early return path nor
reinserted for automatic scheduler cleanup, the job structure appears to be
permanently orphaned.
> + }
>
> xe_gt_assert(guc_to_gt(guc), !exec_queue_destroyed(q));
>
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261012055053.964468-5-satyanarayana.k.v.p@intel.com?part=2
next prev parent reply other threads:[~2026-10-12 6:01 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-12 5:50 [PATCH v5 0/3] Fix kernel crash during driver teardown Satyanarayana K V P
2026-10-12 5:50 ` [PATCH v5 1/3] drm/xe: Prevent VF memory IRQ from accessing a torn-down engine Satyanarayana K V P
2026-10-12 6:07 ` sashiko-bot
2026-10-12 8:29 ` Piotr Piórkowski
2026-10-12 5:50 ` [PATCH v5 2/3] drm/xe/guc: Protect timeout handling from device unplug Satyanarayana K V P
2026-10-12 6:00 ` sashiko-bot [this message]
2026-10-12 5:50 ` [PATCH v5 3/3] drm/xe/gt: Disable GT reset worker before engine teardown Satyanarayana K V P
2026-10-12 8:40 ` Piotr Piórkowski
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-167695@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=satyanarayana.k.v.p@intel.com \
/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.