Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: John Harrison <john.c.harrison@intel.com>
To: Andi Shyti <andi.shyti@linux.intel.com>
Cc: Intel-GFX@lists.freedesktop.org, DRI-Devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915/guc: Fix potential null pointer deref in GuC 'steal id' test
Date: Mon, 7 Aug 2023 12:46:46 -0700	[thread overview]
Message-ID: <989e6e1c-cac3-58be-19d1-2c2468615cd6@intel.com> (raw)
In-Reply-To: <ZMurfYjREPl5NIGB@ashyti-mobl2.lan>

On 8/3/2023 06:28, Andi Shyti wrote:
> Hi John,
>
> On Wed, Aug 02, 2023 at 11:49:40AM -0700, John.C.Harrison@Intel.com wrote:
>> From: John Harrison <John.C.Harrison@Intel.com>
>>
>> It was noticed that if the very first 'stealing' request failed to
>> create for some reason then the 'steal all ids' loop would immediately
>> exit with 'last' still being NULL. The test would attempt to continue
>> but using a null pointer. Fix that by aborting the test if it fails to
>> create any requests at all.
>>
>> Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
>> ---
>>   drivers/gpu/drm/i915/gt/uc/selftest_guc.c | 6 +++---
>>   1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gt/uc/selftest_guc.c b/drivers/gpu/drm/i915/gt/uc/selftest_guc.c
>> index 1fd760539f77b..bfb72143566f6 100644
>> --- a/drivers/gpu/drm/i915/gt/uc/selftest_guc.c
>> +++ b/drivers/gpu/drm/i915/gt/uc/selftest_guc.c
>> @@ -204,9 +204,9 @@ static int intel_guc_steal_guc_ids(void *arg)
>>   		if (IS_ERR(rq)) {
>>   			ret = PTR_ERR(rq);
>>   			rq = NULL;
>> -			if (ret != -EAGAIN) {
>> -				guc_err(guc, "Failed to create request %d: %pe\n",
>> -					context_index, ERR_PTR(ret));
>> +			if ((ret != -EAGAIN) || !last) {
> isn't last alway NULL here?
>
> Andi
No, only on the first pass around the loop. When a request is 
successfully created, the else clause below assigns last to that new 
request. So if the failure to create only happens on pass 2 or later, 
last will be non-null. Which is the whole point of the code. It keeps 
creating all the contexts/requests that it can until it runs out of 
resources and gets an EAGAIN failure. At which point, last will be 
pointing to the last successful creation and the test continues to the 
next part of actually stealing an id.

But if the EAGAIN failure happens on the first pass then last will be 
null and it is not safe/valid to proceed so it needs to abort. And if 
anything other than EAGAIN is returned then something has gone wrong and 
it doesn't matter what last is set to, it needs to abort regardless.

John.


>
>> +				guc_err(guc, "Failed to create %srequest %d: %pe\n",
>> +					last ? "" : "first ", context_index, ERR_PTR(ret));
>>   				goto err_spin_rq;
>>   			}
>>   		} else {
>> -- 
>> 2.39.1


  reply	other threads:[~2023-08-07 19:47 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-02 18:49 [Intel-gfx] [PATCH] drm/i915/guc: Fix potential null pointer deref in GuC 'steal id' test John.C.Harrison
2023-08-02 21:36 ` [Intel-gfx] ✓ Fi.CI.BAT: success for " Patchwork
2023-08-03  1:50 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2023-08-03 13:28 ` [Intel-gfx] [PATCH] " Andi Shyti
2023-08-07 19:46   ` John Harrison [this message]
2023-08-10  9:50     ` Andi Shyti

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=989e6e1c-cac3-58be-19d1-2c2468615cd6@intel.com \
    --to=john.c.harrison@intel.com \
    --cc=DRI-Devel@lists.freedesktop.org \
    --cc=Intel-GFX@lists.freedesktop.org \
    --cc=andi.shyti@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