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

[sashiko-bot]

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

New issues:
- [High] Dropping the FPU guard inside dc_create_plane_state() and the error path of dc_create_stream_for_sink() corrupts callee-saved FPU registers on architectures like ARM64.

Pre-existing issues:
- [High] The patch addresses 'scheduling while atomic' bugs on PREEMPT_RT by wrapping memory allocations in FPU regions, but fails to apply the same fix to the symmetrical normal deallocation paths (dc_stream_free and dc_plane_state_free).
--

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

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.

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

> 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 dbc12640b01c0..4ac835777b586 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_stream.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_stream.c
> @@ -233,8 +233,9 @@ struct dc_stream_state *dc_create_stream_for_sink(
>  
>  fail:
>  	if (stream) {
> -		kfree(stream->update_scratch);
> -		kfree(stream);
> +		if (stream->update_scratch)
> +			DC_RUN_WITH_PREEMPTION_ENABLED(kfree(stream->update_scratch));
> +		DC_RUN_WITH_PREEMPTION_ENABLED(kfree(stream));
>  	}
>  
>  	return NULL;

[Severity: High]
Could this cause floating-point data corruption on architectures like ARM64?

If this error path is reached while a DML algorithm is calling this as a
callback inside an FPU block, DC_RUN_WITH_PREEMPTION_ENABLED() terminates
the kernel FPU context. 

When kernel_fpu_end() restores the user FPU state, won't the floating-point
variables held in callee-saved FPU registers be destroyed upon returning to
the DML caller?

> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_surface.c b/drivers/gpu/drm/amd/display/dc/core/dc_surface.c
> index 88e825a6582cb..d5c6427796b65 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_surface.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_surface.c
> @@ -85,8 +85,8 @@ uint8_t  dc_plane_get_pipe_mask(struct dc_state *dc_state, const struct dc_plane
>   ******************************************************************************/
>  struct dc_plane_state *dc_create_plane_state(const struct dc *dc)
>  {
> -	struct dc_plane_state *plane_state = kvzalloc_obj(*plane_state,
> -							  GFP_ATOMIC);
> +	struct dc_plane_state *plane_state;
> +	DC_RUN_WITH_PREEMPTION_ENABLED(plane_state = kvzalloc_obj(*plane_state, GFP_ATOMIC));

[Severity: High]
Similar to the stream allocation above, does dropping the FPU guard here
corrupt callee-saved FPU registers?

When a DML algorithm calls dc_state_create_phantom_plane as a callback while
inside an FPU block, it calls dc_create_plane_state(). 

Dropping the FPU guard here allows the hardware FPU state to be overwritten,
which appears to destroy the caller's FPU context.

>  
>  	if (NULL == plane_state)
>  		return NULL;

[Severity: High]
This isn't a bug introduced by this patch, but since you are addressing
'scheduling while atomic' bugs on PREEMPT_RT by wrapping memory allocations
in FPU regions, what about the symmetrical normal deallocation paths?

For example, dc_stream_free() and dc_plane_state_free() call kfree() and
kvfree() without FPU/preemption guards.

During bandwidth validation, dcn32_internal_validate_bw() executes inside an
FPU-guarded section (with preemption disabled) and can trigger these frees:

dcn32_internal_validate_bw()
  dc_state_release_phantom_streams_and_planes()
    // drops refcounts, leading to:
    dc_stream_free()
      kfree()

On PREEMPT_RT kernels, won't these free functions still attempt to acquire
sleeping locks (rt_mutex) and cause a scheduling while atomic crash?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260727105059.75716-1-spasswolf@xxxxxx?part=1