All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Javier MV" <javiermv@gmail.com>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 2/2] drm/i915/guc: Don't unblock a banned context
Date: Tue, 10 Nov 2026 13:07:50 +0000	[thread overview]
Message-ID: <sashiko-outbox-207084@kernel.org> (raw)
In-Reply-To: <20261110122534.12989-3-javiermv@gmail.com>

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] drm/i915/guc: context_cant_unblock() misses exiting contexts
  on unblock
--

commit f3c1b0cc59baf35aaa07862b720ef5529fd5baed
Author: Javier MV <javiermv@duck.com>

drm/i915/guc: Don't unblock a banned context

This commit adds an intel_context_is_banned() check to
context_cant_unblock() so that guc_context_unblock() does not re-enable
scheduling on a banned context after the schedule-disable done handler
clears SCHED_STATE_BANNED.

Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15301

> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> index 555ca8fdf64af..eb1d010ed3dcc 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> @@ -3182,7 +3182,12 @@ static bool context_cant_unblock(struct intel_context *ce)
>  {
>  	lockdep_assert_held(&ce->guc_state.lock);
>  
> +	/*
> +	 * SCHED_STATE_BANNED alone isn't enough: the sched disable done
> +	 * handler clears it.
> +	 */
>  	return (ce->guc_state.sched_state & SCHED_STATE_NO_UNBLOCK) ||
> +		intel_context_is_banned(ce) ||
>  		context_guc_id_invalid(ce) ||
>  		!ctx_id_mapped(ce_to_guc(ce), ce->guc_id.id) ||
>  		!intel_context_is_pinned(ce);

[Severity: Medium]
Should this check !intel_context_is_schedulable(ce) instead of
intel_context_is_banned(ce)?

intel_context_revoke() sets CONTEXT_EXITING (not CONTEXT_BANNED) via
intel_context_set_exiting() before calling guc_context_revoke(), which
then takes the same SCHED_STATE_BANNED path as a banned context.  If
intel_context_revoke() (for example on context close or process exit for
a non-persistent context) races with guc_context_cancel_request() while
the block schedule-disable is pending, intel_guc_sched_done_process_msg()
clears SCHED_STATE_BANNED and cancels the inflight requests with -EIO.

When guc_context_cancel_request() resumes, guc_reset_state() sees
!intel_context_is_schedulable(ce) and returns early without scrubbing the
LRC or advancing the ring head, and then guc_context_unblock() re-enables
scheduling in GuC for the revoked context with an un-scrubbed ring and
already-completed requests.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261110122534.12989-1-javiermv@gmail.com?part=2

  reply	other threads:[~2026-11-10 13:08 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-10 12:24 [PATCH 0/2] drm/i915/guc: Fix requests of a banned context never completing Javier MV
2026-11-10 12:24 ` [PATCH 1/2] drm/i915/guc: Complete all requests of a non-schedulable context Javier MV
2026-11-10 12:56   ` sashiko-bot
2026-11-10 12:24 ` [PATCH 2/2] drm/i915/guc: Don't unblock a banned context Javier MV
2026-11-10 13:07   ` sashiko-bot [this message]
2026-11-10 15:11 ` ✗ LGCI.VerificationFailed: failure for drm/i915/guc: Fix requests of a banned context never completing Patchwork
2026-11-11 15:29 ` [PATCH 0/2] " Javier MV

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-207084@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=javiermv@gmail.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.