Re: [PATCH v3 3/3] accel/rocket: Propagate job submission errors

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Unrecoverable partial job submission due to missing progress reporting.
--

commit 62a6d62ce92d524109acbfd3cf943820e07879c2
Author: MoGGuU <Naixumogu@whut.edu.cn>

accel/rocket: Propagate job submission errors

This commit updates rocket_ioctl_submit() to return the first error
encountered during job submission and stop processing remaining jobs.
Previously, errors from individual job submissions were ignored.

> diff --git a/drivers/accel/rocket/rocket_job.c b/drivers/accel/rocket/rocket_job.c
> index b55e12aecfe64..8f1bdf4a57f20 100644
> --- a/drivers/accel/rocket/rocket_job.c
> +++ b/drivers/accel/rocket/rocket_job.c
> @@ -646,8 +646,11 @@ int rocket_ioctl_submit(struct drm_device *dev, void *data, struct drm_file *fil
>  	}
>  
> -	for (i = 0; i < args->job_count; i++)
> -		rocket_ioctl_submit_job(dev, file, &jobs[i]);
> +	for (i = 0; i < args->job_count; i++) {
> +		ret = rocket_ioctl_submit_job(dev, file, &jobs[i]);
> +		if (ret)
> +			goto exit;
> +	}
>  
>  exit:
>  	kvfree(jobs);

[Severity: High]
How does userspace determine how many jobs were successfully submitted before
the error occurred?

When rocket_ioctl_submit() halts on the first error, the previously submitted 
jobs remain queued, giving ordered partial-submit semantics. However, looking
at the UAPI struct drm_rocket_submit in include/uapi/drm/rocket_accel.h:

struct drm_rocket_submit {
        __u64 jobs;
        __u32 job_count;
        __u32 job_struct_size;
        __u64 reserved;
};

There is no output field (like jobs_submitted) to communicate the partial
success state back to userspace, and the kernel does not modify the incoming
job_count.

Without knowing the index of the failed job, if a user application encounters
an error (for example, due to an invalid BO handle or memory allocation
failure), how can it safely recover? 

If userspace retries the submission, it risks double-submitting already
queued jobs, which can corrupt hardware state. If it aborts entirely, it may
hang waiting for implicit fences on BOs that were successfully submitted.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260828050805.38548-1-Naixumogu@whut.edu.cn?part=3