From: Maciej Patelczyk <maciej.patelczyk@intel.com>
To: Jakub Legowski <jakub.legowski@intel.com>,
<intel-xe@lists.freedesktop.org>
Cc: <matthew.brost@intel.com>
Subject: Re: [PATCH v2 1/1] drm/xe/guc: Fix wake_up race in handle_sched_done
Date: Thu, 10 Sep 2026 12:20:07 +0200 [thread overview]
Message-ID: <62f487d6-a673-47ef-91c5-66232a0d910e@intel.com> (raw)
In-Reply-To: <20260909070825.228551-1-jakub.legowski@intel.com>
On 09/09/2026 09:08, Jakub Legowski wrote:
> Move wake_up_all() after clear_exec_queue_pending_disable()
>
> When a SCHED_DONE G2H arrives for a banned exec queue,
> handle_sched_done() calls wake_up_all() before
> clear_exec_queue_pending_disable(). This creates a race with the
> wait_event_timeout() in guc_exec_queue_timedout_job() that waits
> for pending_disable to be cleared:
>
> smp_rmb();
> ret = wait_event_timeout(guc->ct.wq,
> ...
> ...);
>
> This was observed as:
> [drm:guc_exec_queue_timedout_job [xe]] Tile0: GT0: Check job timeout: seqno=4294967169, lrc_seqno=4294967169, guc_id=4, running_time_ms=0, timeout_ms=5000, diff=0x00000001
>
> Moving the wake_up_all() (along with its smp_wmb())
> after all paths that clear pending_disable, ensuring that waiters
> always observe the updated state when woken.
>
> Same as for runnable_state == 1 in the beginning of
> handle_sched_done().
>
> Signed-off-by: Jakub Legowski <jakub.legowski@intel.com>
> ---
> drivers/gpu/drm/xe/xe_guc_submit.c | 30 ++++++++++++++++--------------
> 1 file changed, 16 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/xe/xe_guc_submit.c b/drivers/gpu/drm/xe/xe_guc_submit.c
> index 99d8c807ff05..a181b5042293 100644
> --- a/drivers/gpu/drm/xe/xe_guc_submit.c
> +++ b/drivers/gpu/drm/xe/xe_guc_submit.c
> @@ -3239,25 +3239,27 @@ static void handle_sched_done(struct xe_guc *guc, struct xe_exec_queue *q,
> clear_exec_queue_pending_disable(q);
> suspend_fence_signal(q);
> } else {
> + bool destroyed = exec_queue_destroyed(q);
> +
> + /*
> + * Make sure to clear the pending_disable only
> + * after sampling the destroyed state. We want
> + * to ensure we don't trigger the unregister too
> + * early with something intending to only
> + * disable scheduling. The caller doing the
> + * destroy must wait for an ongoing
> + * pending_disable before marking as destroyed.
> + */
> + clear_exec_queue_pending_disable(q);
> +
> if (exec_queue_banned(q)) {
> + /* Pairs with smp_rmb in guc_exec_queue_timedout_job */
> smp_wmb();
> wake_up_all(&guc->ct.wq);
> }
> - if (exec_queue_destroyed(q)) {
> - /*
> - * Make sure to clear the pending_disable only
> - * after sampling the destroyed state. We want
> - * to ensure we don't trigger the unregister too
> - * early with something intending to only
> - * disable scheduling. The caller doing the
> - * destroy must wait for an ongoing
> - * pending_disable before marking as destroyed.
> - */
> - clear_exec_queue_pending_disable(q);
> +
> + if (destroyed)
> deregister_exec_queue(guc, q);
> - } else {
> - clear_exec_queue_pending_disable(q);
> - }
> }
> }
> }
Apply suggested changes by Matthew.
Looks good.
Reviewed-by: Maciej Patelczyk <maciej.patelczyk@intel.com>
prev parent reply other threads:[~2026-09-10 10:20 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-09 7:08 [PATCH v2 1/1] drm/xe/guc: Fix wake_up race in handle_sched_done Jakub Legowski
2026-09-09 7:30 ` sashiko-bot
2026-09-09 7:42 ` ✗ CI.checkpatch: warning for series starting with [v2,1/1] " Patchwork
2026-09-09 7:44 ` ✓ CI.KUnit: success " Patchwork
2026-09-09 8:23 ` ✓ Xe.CI.BAT: " Patchwork
2026-09-09 12:57 ` ✗ Xe.CI.FULL: failure " Patchwork
2026-09-10 0:00 ` [PATCH v2 1/1] " Matthew Brost
2026-09-10 10:20 ` Maciej Patelczyk [this message]
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=62f487d6-a673-47ef-91c5-66232a0d910e@intel.com \
--to=maciej.patelczyk@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=jakub.legowski@intel.com \
--cc=matthew.brost@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.