Re: [PATCH v14 04/15] accel/rocket: let the core suspend after a reset

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] pm_runtime: asynchronous pm_runtime_put_autosuspend() during reset aborts hardware recovery
--

commit 95b09cd74a75566f037a5b7f059c69a7c6b7352e
Author: Jiaxing Hu <gahing@gahingwoo.com>
accel/rocket: let the core suspend after a reset

This commit changes the PM counter decrement in rocket_reset() from
pm_runtime_put_noidle() to pm_runtime_put_autosuspend() to allow the
core to suspend.

Link: https://lore.kernel.org/all/20260819073530.6087-1-royalnet026@gmail.com/

> diff --git a/drivers/accel/rocket/rocket_job.c b/drivers/accel/rocket/rocket_job.c
> --- a/drivers/accel/rocket/rocket_job.c
> +++ b/drivers/accel/rocket/rocket_job.c
> @@ -443,12 +443,12 @@ rocket_reset(struct rocket_core *core, struct drm_sched_job *bad)
[ ... ]
>  	scoped_guard(mutex, &core->job_lock) {
>  		if (core->in_flight_job)
> -			pm_runtime_put_noidle(core->dev);
> +			pm_runtime_put_autosuspend(core->dev);

[Severity: High]
Does this asynchronous suspend abort the hardware recovery process?

When a job times out and triggers rocket_reset(), this code now schedules
an asynchronous suspend.

However, at the end of rocket_reset(), drm_sched_start() is immediately
invoked to restart the DRM scheduler. If there are pending jobs in the
queue, the scheduler thread can immediately pull the next job and call
pm_runtime_resume_and_get().

This increments the PM usage count and cancels the pending autosuspend
before the timer expires. Consequently, the device might never enter
RPM_SUSPENDED, its power domain never cycles, and the required bus
interface reset fails to trigger.

This leaves the bus interface stuck, causing the IOMMU to stop answering
and plunging the accelerator into an infinite timeout loop. This
regression can occur when user space submits a batch of jobs and one
induces a timeout, leading to a local denial of service.

Would it be safer to use pm_runtime_put_sync() here? 

Using a synchronous put ensures the device is fully suspended before the
next operation proceeds, which aligns with the requirement for hardware
ordering constraints.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260924102135.92217-1-gahing@gahingwoo.com?part=4