All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Lizhi Hou" <lizhi.hou@amd.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH V1] accel/amdxdna: Prevent PM resume deadlock in hwctx_sync_debug_bo()
Date: Tue, 16 Jun 2026 06:29:54 +0000	[thread overview]
Message-ID: <20260616062955.3B3261F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260616062008.3533989-1-lizhi.hou@amd.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Mixing `goto` and `guard()` causes undefined behavior/build error
--

commit e82723d9f7a656583eeaed6e8880da6e23ecb6df
Author: Lizhi Hou <lizhi.hou@amd.com>

accel/amdxdna: Prevent PM resume deadlock in hwctx_sync_debug_bo()

This commit reorders amdxdna_pm_resume_get() to execute before acquiring
xdna->dev_lock. This prevents a potential deadlock that occurs if the
device is suspended during the callback.

> diff --git a/drivers/accel/amdxdna/amdxdna_ctx.c b/drivers/accel/amdxdna/amdxdna_ctx.c
> index 855da8c79a1cd..20e2fd096c913 100644
> --- a/drivers/accel/amdxdna/amdxdna_ctx.c
> +++ b/drivers/accel/amdxdna/amdxdna_ctx.c
> @@ -412,16 +412,25 @@ int amdxdna_hwctx_sync_debug_bo(struct amdxdna_client *client, u32 debug_bo_hdl)
>  	if (!gobj)
>  		return -EINVAL;
>  
> +	ret = amdxdna_pm_resume_get(xdna);
> +	if (ret) {
> +		XDNA_ERR(xdna, "Resume failed, ret %d", ret);
> +		goto put_obj;
> +	}
> +
>  	abo = to_xdna_obj(gobj);
>  	guard(mutex)(&xdna->dev_lock);

[Severity: High]
Does jumping forward over the guard(mutex) declaration with the goto put_obj
statement above trigger a compilation error?

Jumping over a variable initialized with __attribute__((cleanup)) is usually
rejected by modern compilers. If a compiler allowed it, the destructor would
execute at the end of the function using uninitialized stack memory for the
lock pointer, causing a kernel panic.

Additionally, include/linux/cleanup.h notes that mixing goto-based error
handling and scope-based cleanups in the same function should be avoided to
prevent issues like this.

>  	hwctx = xa_load(&client->hwctx_xa, abo->assigned_hwctx);
>  	if (!hwctx) {
>  		ret = -EINVAL;
> -		goto put_obj;
> +		goto suspend_put;
>  	}
>  
>  	ret = xdna->dev_info->ops->hwctx_sync_debug_bo(hwctx, debug_bo_hdl);
>  
> +suspend_put:
> +	amdxdna_pm_suspend_put(xdna);
> +
>  put_obj:
>  	drm_gem_object_put(gobj);
>  	return ret;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260616062008.3533989-1-lizhi.hou@amd.com?part=1

      reply	other threads:[~2026-06-16  6:29 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-16  6:20 [PATCH V1] accel/amdxdna: Prevent PM resume deadlock in hwctx_sync_debug_bo() Lizhi Hou
2026-06-16  6:29 ` sashiko-bot [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=20260616062955.3B3261F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=lizhi.hou@amd.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.