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 <[email protected]> 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/[email protected]?part=1
