Re: [PATCH] drm/amd/display: fix usage of DC_FPU_{BEGIN,END} with PREEMPT_RT

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] The patch wraps allocations and error-path frees in DC_RUN_WITH_PREEMPTION_ENABLED() to fix a 'scheduling while atomic' bug on PREEMPT_RT, but misses the normal destruction paths which are called from the exact same FPU-guarded contexts.
- [Medium] dc_state_create_phantom_stream() leaks a phantom stream reference if tracking fails.
--

--- Patch [1]: [PATCH] drm/amd/display: fix usage of DC_FPU_{BEGIN,END} with PREEMPT_RT ---
commit 333ce260a6d2d044dc84469ac2172b5e7123c941
Author: Bert Karwatzki <spasswolf@web.de>

drm/amd/display: fix usage of DC_FPU_{BEGIN,END} with PREEMPT_RT

On PREEMPT_RT kernels kvzalloc_obj() can sleep because spin_lock is
converted to rt_mutex. dc_create_plane_state() can be called while
inside an FPU-guarded region, resuling in "scheduling while atomic"
errors on PREEMPT_RT kernels.
Fix this by calling kvzalloc_obj() with DC_RUN_WITH_PREEMPTION_ENABLED().
Also fix the error path in dc_create_stream_for_sink().

Link: https://lore.kernel.org/lkml/20260723123449.6494-1-spasswolf@web.de/

> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_stream.c b/drivers/gpu/drm/amd/display/dc/core/dc_stream.c
> index cdcf140bc1bbd..accad9e20e88a 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_stream.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_stream.c
> @@ -229,7 +229,7 @@ struct dc_stream_state *dc_create_stream_for_sink(
>  
>  fail:
>  	if (stream)
> -		kfree(stream);
> +		DC_RUN_WITH_PREEMPTION_ENABLED(kfree(stream));

[Severity: High]
This isn't a bug introduced by this patch, but does this fix need to cover the
normal destruction paths as well?

The patch wraps allocations and error-path frees to prevent scheduling while
atomic errors on PREEMPT_RT kernels. However, normal destruction paths are
also called from the exact same FPU-guarded contexts.

For example, when dropping phantom streams inside an FPU-guarded block during
DML bandwidth validation:

dcn32_internal_validate_bw()
   dc_state_release_phantom_streams_and_planes()
      dc_stream_free()
         kfree(stream);
      dc_plane_state_free()
         kvfree(plane_state);

Should dc_stream_free() and dc_plane_state_free() also wrap their frees with
DC_RUN_WITH_PREEMPTION_ENABLED() to avoid triggering the same panic?

[Severity: Medium]
This is a pre-existing issue, but does dc_state_create_phantom_stream() in
drivers/gpu/drm/amd/display/dc/core/dc_state.c leak a phantom stream
reference if tracking fails?

If dc_state_track_phantom_stream() fails, for example because the
MAX_PHANTOM_PIPES limit is reached, it returns false. This return value is
ignored by dc_state_create_phantom_stream(). The stream is added to the main
array but not tracked in the phantom array.

When the state is destroyed, dc_state_destruct() only drops the reference
from the main array, permanently leaking the initial creation reference.

>  
>  	return NULL;
>  }

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260801071724.12998-1-spasswolf@web.de?part=1