* [PATCH] drm/v3d: fix to avoid cleaning up uninitialized CPU jobs
@ 2026-05-25 14:04 Jeongjun Park
2026-05-28 19:14 ` Maíra Canal
0 siblings, 1 reply; 4+ messages in thread
From: Jeongjun Park @ 2026-05-25 14:04 UTC (permalink / raw)
To: Melissa Wen, Maíra Canal
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, Iago Toral Quiroga, dri-devel,
linux-kernel, stable, Jeongjun Park
The CPU submit ioctl checks cpu_job->job_type before the CPU job has been
initialized with v3d_job_init(). When no CPU job extension is supplied,
the check fails and the ioctl goes to the common error path.
That path calls v3d_job_cleanup(), which expects a fully initialized
v3d_job. However at this point the CPU job has only been allocated,
so the embedded DRM scheduler job state has not been initialized yet.
Initialize the CPU job after parsing extensions, but before validating
the CPU job type and BO count. Keep pre-initialization failures on a
separate path that only deallocates the job and releases multisync
post-dependencies. Also use the CPU-job release callback so initialized
CPU jobs are released through the normal cleanup path.
Cc: stable@kernel.org
Fixes: aafc1a2bea67 ("drm/v3d: Add a CPU job submission")
Signed-off-by: Jeongjun Park <aha310510@gmail.com>
---
drivers/gpu/drm/v3d/v3d_submit.c | 19 +++++++++++--------
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_submit.c b/drivers/gpu/drm/v3d/v3d_submit.c
index 3ddd53b6f437..f5a1b388eaa3 100644
--- a/drivers/gpu/drm/v3d/v3d_submit.c
+++ b/drivers/gpu/drm/v3d/v3d_submit.c
@@ -1300,10 +1300,18 @@ v3d_submit_cpu_ioctl(struct drm_device *dev, void *data,
ret = v3d_get_extensions(file_priv, args->extensions, &se, cpu_job);
if (ret) {
drm_dbg(dev, "Failed to get extensions.\n");
- goto fail;
+ v3d_job_deallocate((void *)&cpu_job);
+ goto fail_init;
}
}
+ ret = v3d_job_init(v3d, file_priv, &cpu_job->base,
+ v3d_cpu_job_free, 0, &se, V3D_CPU);
+ if (ret) {
+ v3d_job_deallocate((void *)&cpu_job);
+ goto fail_init;
+ }
+
/* Every CPU job must have a CPU job user extension */
if (!cpu_job->job_type) {
drm_dbg(dev, "CPU job must have a CPU job user extension.\n");
@@ -1319,13 +1327,6 @@ v3d_submit_cpu_ioctl(struct drm_device *dev, void *data,
trace_v3d_submit_cpu_ioctl(&v3d->drm, cpu_job->job_type);
- ret = v3d_job_init(v3d, file_priv, &cpu_job->base,
- v3d_cpu_job_free, 0, &se, V3D_CPU);
- if (ret) {
- v3d_job_deallocate((void *)&cpu_job);
- goto fail;
- }
-
clean_job = cpu_job->indirect_csd.clean_job;
csd_job = cpu_job->indirect_csd.job;
@@ -1402,6 +1403,8 @@ v3d_submit_cpu_ioctl(struct drm_device *dev, void *data,
v3d_job_cleanup((void *)cpu_job);
v3d_job_cleanup((void *)csd_job);
v3d_job_cleanup(clean_job);
+
+fail_init:
v3d_put_multisync_post_deps(&se);
return ret;
--
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [PATCH] drm/v3d: fix to avoid cleaning up uninitialized CPU jobs
2026-05-25 14:04 [PATCH] drm/v3d: fix to avoid cleaning up uninitialized CPU jobs Jeongjun Park
@ 2026-05-28 19:14 ` Maíra Canal
2026-06-02 15:41 ` Jeongjun Park
0 siblings, 1 reply; 4+ messages in thread
From: Maíra Canal @ 2026-05-28 19:14 UTC (permalink / raw)
To: Jeongjun Park, Melissa Wen
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, Iago Toral Quiroga, dri-devel,
linux-kernel, stable
Hi Jeongjun,
On 25/05/26 11:04, Jeongjun Park wrote:
> The CPU submit ioctl checks cpu_job->job_type before the CPU job has been
> initialized with v3d_job_init(). When no CPU job extension is supplied,
> the check fails and the ioctl goes to the common error path.
>
> That path calls v3d_job_cleanup(), which expects a fully initialized
> v3d_job. However at this point the CPU job has only been allocated,
> so the embedded DRM scheduler job state has not been initialized yet.
>
> Initialize the CPU job after parsing extensions, but before validating
> the CPU job type and BO count. Keep pre-initialization failures on a
Considering that this is a minimal fix for stable, could you explain me
why do you believe moving v3d_job_init() is the best solution?
Best regards,
- Maíra
> separate path that only deallocates the job and releases multisync
> post-dependencies. Also use the CPU-job release callback so initialized
> CPU jobs are released through the normal cleanup path.
>
> Cc: stable@kernel.org
> Fixes: aafc1a2bea67 ("drm/v3d: Add a CPU job submission")
> Signed-off-by: Jeongjun Park <aha310510@gmail.com>
> ---
> drivers/gpu/drm/v3d/v3d_submit.c | 19 +++++++++++--------
> 1 file changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/v3d/v3d_submit.c b/drivers/gpu/drm/v3d/v3d_submit.c
> index 3ddd53b6f437..f5a1b388eaa3 100644
> --- a/drivers/gpu/drm/v3d/v3d_submit.c
> +++ b/drivers/gpu/drm/v3d/v3d_submit.c
> @@ -1300,10 +1300,18 @@ v3d_submit_cpu_ioctl(struct drm_device *dev, void *data,
> ret = v3d_get_extensions(file_priv, args->extensions, &se, cpu_job);
> if (ret) {
> drm_dbg(dev, "Failed to get extensions.\n");
> - goto fail;
> + v3d_job_deallocate((void *)&cpu_job);
> + goto fail_init;
> }
> }
>
> + ret = v3d_job_init(v3d, file_priv, &cpu_job->base,
> + v3d_cpu_job_free, 0, &se, V3D_CPU);
> + if (ret) {
> + v3d_job_deallocate((void *)&cpu_job);
> + goto fail_init;
> + }
> +
> /* Every CPU job must have a CPU job user extension */
> if (!cpu_job->job_type) {
> drm_dbg(dev, "CPU job must have a CPU job user extension.\n");
> @@ -1319,13 +1327,6 @@ v3d_submit_cpu_ioctl(struct drm_device *dev, void *data,
>
> trace_v3d_submit_cpu_ioctl(&v3d->drm, cpu_job->job_type);
>
> - ret = v3d_job_init(v3d, file_priv, &cpu_job->base,
> - v3d_cpu_job_free, 0, &se, V3D_CPU);
> - if (ret) {
> - v3d_job_deallocate((void *)&cpu_job);
> - goto fail;
> - }
> -
> clean_job = cpu_job->indirect_csd.clean_job;
> csd_job = cpu_job->indirect_csd.job;
>
> @@ -1402,6 +1403,8 @@ v3d_submit_cpu_ioctl(struct drm_device *dev, void *data,
> v3d_job_cleanup((void *)cpu_job);
> v3d_job_cleanup((void *)csd_job);
> v3d_job_cleanup(clean_job);
> +
> +fail_init:
> v3d_put_multisync_post_deps(&se);
>
> return ret;
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [PATCH] drm/v3d: fix to avoid cleaning up uninitialized CPU jobs
2026-05-28 19:14 ` Maíra Canal
@ 2026-06-02 15:41 ` Jeongjun Park
2026-06-02 15:48 ` Maíra Canal
0 siblings, 1 reply; 4+ messages in thread
From: Jeongjun Park @ 2026-06-02 15:41 UTC (permalink / raw)
To: Maíra Canal
Cc: Melissa Wen, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, Iago Toral Quiroga, dri-devel,
linux-kernel, stable
Hi Maíra,
Maíra Canal <mcanal@igalia.com> wrote:
>
> Hi Jeongjun,
>
> On 25/05/26 11:04, Jeongjun Park wrote:
> > The CPU submit ioctl checks cpu_job->job_type before the CPU job has been
> > initialized with v3d_job_init(). When no CPU job extension is supplied,
> > the check fails and the ioctl goes to the common error path.
> >
> > That path calls v3d_job_cleanup(), which expects a fully initialized
> > v3d_job. However at this point the CPU job has only been allocated,
> > so the embedded DRM scheduler job state has not been initialized yet.
> >
> > Initialize the CPU job after parsing extensions, but before validating
> > the CPU job type and BO count. Keep pre-initialization failures on a
>
> Considering that this is a minimal fix for stable, could you explain me
> why do you believe moving v3d_job_init() is the best solution?
>
Because according to the implementation of v3d_submit_cpu_ioctl(),
v3d_job_cleanup() should never be called when v3d_job_init() fails to
execute successfully, but it is currently being called.
Therefore, I called the init function before the job_type check and added
the missing v3d_job_deallocate(), which should be called when
v3d_get_extensions() fails. However, upon re-analysis, it appears that
adding the fail_init label is unnecessary now, and I have discovered
another serious issue.
If v3d_job_init() fails after v3d_get_extensions() succeeds, a memory leak
may occur in the memory allocated by v3d_get_extensions(). In such cases,
v3d_job_cleanup() cannot be called, and consequently, v3d_cpu_job_free()
cannot be used either. Therefore, it seems necessary to add a separate
helper function to handle this case.
I will quickly write a v2 patch reflecting these changes.
> Best regards,
> - Maíra
>
Regards,
Jeongjun Park
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] drm/v3d: fix to avoid cleaning up uninitialized CPU jobs
2026-06-02 15:41 ` Jeongjun Park
@ 2026-06-02 15:48 ` Maíra Canal
0 siblings, 0 replies; 4+ messages in thread
From: Maíra Canal @ 2026-06-02 15:48 UTC (permalink / raw)
To: Jeongjun Park
Cc: Melissa Wen, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, Iago Toral Quiroga, dri-devel,
linux-kernel, stable
Hi Jeongjun,
On 02/06/26 12:41, Jeongjun Park wrote:
> Hi Maíra,
>
> Maíra Canal <mcanal@igalia.com> wrote:
>>
>> Hi Jeongjun,
>>
>> On 25/05/26 11:04, Jeongjun Park wrote:
>>> The CPU submit ioctl checks cpu_job->job_type before the CPU job has been
>>> initialized with v3d_job_init(). When no CPU job extension is supplied,
>>> the check fails and the ioctl goes to the common error path.
>>>
>>> That path calls v3d_job_cleanup(), which expects a fully initialized
>>> v3d_job. However at this point the CPU job has only been allocated,
>>> so the embedded DRM scheduler job state has not been initialized yet.
>>>
>>> Initialize the CPU job after parsing extensions, but before validating
>>> the CPU job type and BO count. Keep pre-initialization failures on a
>>
>> Considering that this is a minimal fix for stable, could you explain me
>> why do you believe moving v3d_job_init() is the best solution?
>>
>
> Because according to the implementation of v3d_submit_cpu_ioctl(),
> v3d_job_cleanup() should never be called when v3d_job_init() fails to
> execute successfully, but it is currently being called.
>
> Therefore, I called the init function before the job_type check and added
> the missing v3d_job_deallocate(), which should be called when
> v3d_get_extensions() fails. However, upon re-analysis, it appears that
> adding the fail_init label is unnecessary now, and I have discovered
> another serious issue.
>
> If v3d_job_init() fails after v3d_get_extensions() succeeds, a memory leak
> may occur in the memory allocated by v3d_get_extensions(). In such cases,
> v3d_job_cleanup() cannot be called, and consequently, v3d_cpu_job_free()
> cannot be used either. Therefore, it seems necessary to add a separate
> helper function to handle this case.
>
> I will quickly write a v2 patch reflecting these changes.
I wouldn't worry a lot about this particular issue, as I already
addressed it in [1].
[1]
https://lore.kernel.org/dri-devel/20260510-v3d-sched-misc-fixes-v2-0-ca4aba343ef6@igalia.com/T/
Best regards,
- Maíra
>
>> Best regards,
>> - Maíra
>>
>
> Regards,
> Jeongjun Park
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2026-06-02 15:48 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-05-25 14:04 [PATCH] drm/v3d: fix to avoid cleaning up uninitialized CPU jobs Jeongjun Park
2026-05-28 19:14 ` Maíra Canal
2026-06-02 15:41 ` Jeongjun Park
2026-06-02 15:48 ` Maíra Canal
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®