All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Alexandre Oliva <oliva@gnu.org>,
	Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>,
	John Harrison <John.C.Harrison@intel.com>
Cc: intel-gfx@lists.freedesktop.org, stable@vger.kernel.org
Subject: Re: [Intel-gfx] [PATCH] [i915] avoid infinite retries in GuC/HuC loading
Date: Wed, 22 Mar 2023 16:48:59 -0400	[thread overview]
Message-ID: <ZBtpu1KPKa0IsJ0C@intel.com> (raw)
In-Reply-To: <orjzzlhhg8.fsf@lxoliva.fsfla.org>

On Sun, Mar 12, 2023 at 04:56:23PM -0300, Alexandre Oliva wrote:
> 
> If two or more suitable entries with the same filename are found in
> __uc_fw_auto_select's fw_blobs, and that filename fails to load in the
> first attempt and in the retry, when __uc_fw_auto_select is called for
> the third time, the coincidence of strings will cause it to clear
> file_selected.path at the first hit, so it will return the second hit
> over and over again, indefinitely.
> 
> Of course this doesn't occur with the pristine blob lists, but a
> modified version could run into this, e.g., patching in a duplicate
> entry, or (as in our case) disarming blob loading by remapping their
> names to "/*(DEBLOBBED)*/", given a toolchain that unifies identical
> string literals.
> 
> Of course I'm ready to carry a patchlet to avoid this problem
> triggered by our (GNU Linux-libre's) intentional changes, but I
> figured you might be interested in fail-safing it even in accidental
> backporting circumstances.  I realize it's not entirely foolproof: if
> the same string appears in two entries separated by a different one,
> the infinite loop might still occur.  Catching that even more unlikely
> situation seemed too expensive.
> 
> Link: https://www.fsfla.org/pipermail/linux-libre/2023-March/003506.html
> Cc: intel-gfx@lists.freedesktop.org
> Cc: stable@vger.kernel.org # 6.[12].x
> Signed-off-by: Alexandre Oliva <lxoliva@fsfla.org>

Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: John Harrison <John.C.Harrison@Intel.com>

> ---
>  drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
> index 9d6f571097e6..2b7564a3ed82 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
> @@ -259,7 +259,10 @@ __uc_fw_auto_select(struct drm_i915_private *i915, struct intel_uc_fw *uc_fw)

Since __uc_fw_auto_select is also called from another place,
intel_uc_fw_init_early
out of the intel_uc_fw_fetch infinite loop,
I'm afraid this proposal below could have some side-effect.

I hope Daniele and John have a better understanding and can provide
some guidance or acks here.

>  				uc_fw->file_selected.path = NULL;
>  
>  			continue;
> -		}
> +		} else if (uc_fw->file_wanted.path == blob->path)
> +			/* Avoid retrying forever when neighbor
> +			   entries point to the same path.  */
> +			continue;
>  
>  		uc_fw->file_selected.path = blob->path;
>  		uc_fw->file_wanted.path = blob->path;
> -- 
> 2.25.1
> 
> 
> -- 
> Alexandre Oliva, happy hacker                https://FSFLA.org/blogs/lxo/
>    Free Software Activist                       GNU Toolchain Engineer
> Disinformation flourishes because many people care deeply about injustice
> but very few check the facts.  Ask me about <https://stallmansupport.org>

WARNING: multiple messages have this Message-ID (diff)
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Alexandre Oliva <oliva@gnu.org>,
	Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>,
	John Harrison <John.C.Harrison@intel.com>
Cc: <intel-gfx@lists.freedesktop.org>, <stable@vger.kernel.org>
Subject: Re: [Intel-gfx] [PATCH] [i915] avoid infinite retries in GuC/HuC loading
Date: Wed, 22 Mar 2023 16:48:59 -0400	[thread overview]
Message-ID: <ZBtpu1KPKa0IsJ0C@intel.com> (raw)
In-Reply-To: <orjzzlhhg8.fsf@lxoliva.fsfla.org>

On Sun, Mar 12, 2023 at 04:56:23PM -0300, Alexandre Oliva wrote:
> 
> If two or more suitable entries with the same filename are found in
> __uc_fw_auto_select's fw_blobs, and that filename fails to load in the
> first attempt and in the retry, when __uc_fw_auto_select is called for
> the third time, the coincidence of strings will cause it to clear
> file_selected.path at the first hit, so it will return the second hit
> over and over again, indefinitely.
> 
> Of course this doesn't occur with the pristine blob lists, but a
> modified version could run into this, e.g., patching in a duplicate
> entry, or (as in our case) disarming blob loading by remapping their
> names to "/*(DEBLOBBED)*/", given a toolchain that unifies identical
> string literals.
> 
> Of course I'm ready to carry a patchlet to avoid this problem
> triggered by our (GNU Linux-libre's) intentional changes, but I
> figured you might be interested in fail-safing it even in accidental
> backporting circumstances.  I realize it's not entirely foolproof: if
> the same string appears in two entries separated by a different one,
> the infinite loop might still occur.  Catching that even more unlikely
> situation seemed too expensive.
> 
> Link: https://www.fsfla.org/pipermail/linux-libre/2023-March/003506.html
> Cc: intel-gfx@lists.freedesktop.org
> Cc: stable@vger.kernel.org # 6.[12].x
> Signed-off-by: Alexandre Oliva <lxoliva@fsfla.org>

Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: John Harrison <John.C.Harrison@Intel.com>

> ---
>  drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
> index 9d6f571097e6..2b7564a3ed82 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
> @@ -259,7 +259,10 @@ __uc_fw_auto_select(struct drm_i915_private *i915, struct intel_uc_fw *uc_fw)

Since __uc_fw_auto_select is also called from another place,
intel_uc_fw_init_early
out of the intel_uc_fw_fetch infinite loop,
I'm afraid this proposal below could have some side-effect.

I hope Daniele and John have a better understanding and can provide
some guidance or acks here.

>  				uc_fw->file_selected.path = NULL;
>  
>  			continue;
> -		}
> +		} else if (uc_fw->file_wanted.path == blob->path)
> +			/* Avoid retrying forever when neighbor
> +			   entries point to the same path.  */
> +			continue;
>  
>  		uc_fw->file_selected.path = blob->path;
>  		uc_fw->file_wanted.path = blob->path;
> -- 
> 2.25.1
> 
> 
> -- 
> Alexandre Oliva, happy hacker                https://FSFLA.org/blogs/lxo/
>    Free Software Activist                       GNU Toolchain Engineer
> Disinformation flourishes because many people care deeply about injustice
> but very few check the facts.  Ask me about <https://stallmansupport.org>

  parent reply	other threads:[~2023-03-22 20:49 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-12 19:56 [Intel-gfx] [PATCH] [i915] avoid infinite retries in GuC/HuC loading Alexandre Oliva
2023-03-12 19:56 ` Alexandre Oliva
2023-03-20 23:15 ` [Intel-gfx] ✗ Fi.CI.BUILD: warning for " Patchwork
2023-03-20 23:15 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: " Patchwork
2023-03-20 23:33 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2023-03-21  3:55 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2023-03-22 20:48 ` Rodrigo Vivi [this message]
2023-03-22 20:48   ` [Intel-gfx] [PATCH] [i915] " Rodrigo Vivi
2023-03-23  1:30   ` Alexandre Oliva
2023-03-23  1:30     ` Alexandre Oliva
2023-03-24 18:45 ` John Harrison
2023-03-24 18:45   ` John Harrison
2023-03-26  9:46   ` Alexandre Oliva
2023-03-26  9:46     ` Alexandre Oliva
2023-03-31 19:14     ` John Harrison
2023-03-31 19:14       ` John Harrison
2023-04-02 20:42       ` Alexandre Oliva
2023-04-02 20:42         ` Alexandre Oliva

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=ZBtpu1KPKa0IsJ0C@intel.com \
    --to=rodrigo.vivi@intel.com \
    --cc=John.C.Harrison@intel.com \
    --cc=daniele.ceraolospurio@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=oliva@gnu.org \
    --cc=stable@vger.kernel.org \
    /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.