All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Guangshuo Li" <lgs201920130244@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] accel/amdxdna: fix usage_count leak when autosuspend_delay is negative
Date: Fri, 07 Aug 2026 14:52:16 +0000	[thread overview]
Message-ID: <20260807145217.456851F00A3D@smtp.kernel.org> (raw)
In-Reply-To: <20260807143200.2500342-1-lgs201920130244@gmail.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Deadlock during device teardown due to synchronous runtime PM resume while holding dev_lock
--

--- Patch [1]: [PATCH] accel/amdxdna: fix usage_count leak when autosuspend_delay is negative ---
commit 31ff9d16b70b74f4b276ff67df887f4acb154424
Author: Guangshuo Li <lgs201920130244@gmail.com>

accel/amdxdna: fix usage_count leak when autosuspend_delay is negative

This commit fixes a usage_count leak when autosuspend_delay is negative
by adding a missing pm_runtime_dont_use_autosuspend() call during driver
teardown in amdxdna_pm_fini().

> diff --git a/drivers/accel/amdxdna/amdxdna_pm.c b/drivers/accel/amdxdna/amdxdna_pm.c
> index b1fafddd7ad59..7dcedb7c105f2 100644
> --- a/drivers/accel/amdxdna/amdxdna_pm.c
> +++ b/drivers/accel/amdxdna/amdxdna_pm.c
> @@ -73,6 +73,7 @@ void amdxdna_pm_fini(struct amdxdna_dev *xdna)
>  {
>  	struct device *dev = xdna->ddev.dev;
>  
> +	pm_runtime_dont_use_autosuspend(dev);
>  	pm_runtime_get_noresume(dev);
>  	pm_runtime_forbid(dev);

[Severity: High]
This is a pre-existing issue, but does calling pm_runtime_forbid() here
cause a self-deadlock during device teardown?

If the device is in the RPM_SUSPENDED state when driver unbind occurs,
amdxdna_remove() acquires dev_lock before starting the teardown chain:

drivers/accel/amdxdna/amdxdna_pci_drv.c:amdxdna_remove() {
    mutex_lock(&xdna->dev_lock);
    ...
    xdna->dev_info->ops->fini(xdna);
    ...
}

The teardown chain eventually reaches amdxdna_pm_fini(). Calling
pm_runtime_forbid() triggers a synchronous resume, which in turn invokes the
driver's resume callback. The resume callback then attempts to acquire the
exact same lock:

drivers/accel/amdxdna/amdxdna_pm.c:amdxdna_pm_resume() {
    guard(mutex)(&xdna->dev_lock);
    ...
}

Could this sequence cause the unbind thread to hang indefinitely waiting for
xdna->dev_lock?

>  }

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

      reply	other threads:[~2026-08-07 14:52 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-07 14:32 [PATCH] accel/amdxdna: fix usage_count leak when autosuspend_delay is negative Guangshuo Li
2026-08-07 14:52 ` 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=20260807145217.456851F00A3D@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=lgs201920130244@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.