On Thursday, 25 June 2026 14:40:29 Central European Summer Time Boris Brezillon
wrote:
> If we don't drain the panthor_cleanup_wq before
> unregistering/destroying the panthor_device, we might end up with
> cleanup works that are executed after the device is gone.
>
> Add a drain_workqueue() call in panthor_device_unplug() to prevent
> that.
>
> Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block")
> Fixes: 647810ec2476 ("drm/panthor: Add the MMU/VM logical block")
> Reported-by: [email protected]
> Closes:
> https://sashiko.dev/#/patchset/[email protected]?part=2
> Signed-off-by: Boris Brezillon <[email protected]>
> ---
> drivers/gpu/drm/panthor/panthor_device.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/panthor/panthor_device.c
> b/drivers/gpu/drm/panthor/panthor_device.c
> index 0b25abebb803..a0774e28aa94 100644
> --- a/drivers/gpu/drm/panthor/panthor_device.c
> +++ b/drivers/gpu/drm/panthor/panthor_device.c
> @@ -101,6 +101,11 @@ void panthor_device_unplug(struct panthor_device *ptdev)
> panthor_gpu_unplug(ptdev);
> panthor_pwr_unplug(ptdev);
>
> + /* Make sure works queued to panthor_cleanup_wq are executed
> + * before the device is destroyed.
> + */
> + drain_workqueue(panthor_cleanup_wq);
> +
> pm_runtime_dont_use_autosuspend(ptdev->base.dev);
> pm_runtime_put_sync_suspend(ptdev->base.dev);
>
>
>
I feel like nothing in the driver instance should be allowed to queue new
work to that workqueue while the unplug mutex is being held, and
panthor_sched_unplug should just disable_work_sync all the associated group
release_work items as well. If there's not a strong enough relationship
between a scheduler and the groups to ensure we get all the groups in a
non-racey manner that might not work out cleanly though.
Having a scheduler unplug be completely disconnected from the associated
groups being gone seems counter-intuitive to me.
Kind regards,
Nicolas Frattaroli
