Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] Deadlock (both self-deadlock and AB-BA) between `panthor_device_unplug()` and `panthor_device_reset_work()`. --
--- Patch [1]: [PATCH 01/12] drm/panthor: Disable reset work before unplug --- commit 116cfe13ccbee774afdfc7f2e6251c1738450020 Author: Boris Brezillon <[email protected]> drm/panthor: Disable reset work before unplug This commit disables the reset work during the unplug process to prevent interruptions. > diff --git a/drivers/gpu/drm/panthor/panthor_device.c > b/drivers/gpu/drm/panthor/panthor_device.c > index 0b25abebb803c..e7f5744bc1e31 100644 > --- a/drivers/gpu/drm/panthor/panthor_device.c > +++ b/drivers/gpu/drm/panthor/panthor_device.c > @@ -86,6 +86,9 @@ void panthor_device_unplug(struct panthor_device *ptdev) > */ > drm_dev_unplug(&ptdev->base); > > + /* Make sure we're not interrupted by resets while we're unplugging. */ > + disable_work_sync(&ptdev->reset.work); [Severity: High] Does this introduce a deadlock when the reset work fails? Looking at panthor_device_reset_work(), if the reset fails, it calls panthor_device_unplug(). This would result in panthor_device_unplug() calling disable_work_sync() on the currently executing work item, causing a self-deadlock: panthor_device_reset_work() { ... if (ret) { panthor_device_unplug(ptdev); ... disable_work_sync(&ptdev->reset.work); Additionally, since panthor_device_unplug() acquires ptdev->unplug.lock before calling disable_work_sync(), does this create an AB-BA deadlock if driver removal happens concurrently with a reset failure? The driver removal thread would acquire ptdev->unplug.lock and wait in disable_work_sync(), while the reset work would block trying to acquire ptdev->unplug.lock inside its call to panthor_device_unplug(). > /* We do the rest of the unplug with the unplug lock released, > * future callers will wait on ptdev->unplug.done anyway. > */ -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
