From: John Harrison <john.c.harrison@intel.com>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
<Intel-GFX@Lists.FreeDesktop.Org>
Cc: DRI-Devel@Lists.FreeDesktop.Org
Subject: Re: [Intel-gfx] [PATCH] drm/i915/guc: Fix flag query to not modify state
Date: Tue, 8 Feb 2022 10:53:31 -0800 [thread overview]
Message-ID: <eaf8a239-57c6-69e8-a166-987eb6338acb@intel.com> (raw)
In-Reply-To: <ba8ce5c6-ba11-f2af-917c-9e6e14445d43@linux.intel.com>
On 2/8/2022 01:39, Tvrtko Ursulin wrote:
> On 08/02/2022 02:07, John.C.Harrison@Intel.com wrote:
>> From: John Harrison <John.C.Harrison@Intel.com>
>>
>> A flag query helper was actually writing to the flags word rather than
>> just reading. Fix that. Also update the function's comment as it was
>> out of date.
>>
>> Fixes: 0f7976506de61 ("drm/i915/guc: Rework and simplify locking")
>> Signed-off-by: John Harrison <john.c.harrison@intel.com>
>> ---
>> drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 7 ++-----
>> 1 file changed, 2 insertions(+), 5 deletions(-)
>>
>> 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 b3a429a92c0d..d9f4218f5ef4 100644
>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>> @@ -174,11 +174,8 @@ static inline void init_sched_state(struct
>> intel_context *ce)
>> __maybe_unused
>> static bool sched_state_is_init(struct intel_context *ce)
>> {
>> - /*
>> - * XXX: Kernel contexts can have SCHED_STATE_NO_LOCK_REGISTERED
>> after
>> - * suspend.
>> - */
>> - return !(ce->guc_state.sched_state &=
>> + /* Kernel contexts can have SCHED_STATE_REGISTERED after
>> suspend. */
>> + return !(ce->guc_state.sched_state &
>> ~(SCHED_STATE_BLOCKED_MASK | SCHED_STATE_REGISTERED));
>> }
>
> Looks important - what are the consequences?
Supposedly nothing.
The test was only ever used inside a BUG_ON during context registration.
Rather than asserting that the condition was true, it was making the
condition true. So, in theory, there was no consequence because we
should never have hit a BUG_ON anyway. Which means the write should
always have been a no-op.
>
> Needs Cc: stable for 5.16?
Meaning "Cc: <stable@vger.kernel.org>"? Or is there anything required to
specify 5.16?
John.
>
> Regards,
>
> Tvrtko
next prev parent reply other threads:[~2022-02-08 18:53 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-08 2:07 [Intel-gfx] [PATCH] drm/i915/guc: Fix flag query to not modify state John.C.Harrison
2022-02-08 2:19 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2022-02-08 2:51 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-02-08 6:18 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2022-02-08 9:39 ` [Intel-gfx] [PATCH] " Tvrtko Ursulin
2022-02-08 18:53 ` John Harrison [this message]
2022-02-09 8:27 ` Tvrtko Ursulin
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=eaf8a239-57c6-69e8-a166-987eb6338acb@intel.com \
--to=john.c.harrison@intel.com \
--cc=DRI-Devel@Lists.FreeDesktop.Org \
--cc=Intel-GFX@Lists.FreeDesktop.Org \
--cc=tvrtko.ursulin@linux.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox