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

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 erro=
r path of dc_create_stream_for_sink() corrupts callee-saved FPU registers o=
n architectures like ARM64.

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

--- Patch [1]: [PATCH] drm/amd/display: fix usage of DC_FPU_{BEGIN,END} wit=
h PREEMPT_RT ---
commit cf0d00c09a192f136eba5d73a1ff01aa518ca2f4
Author: Bert Karwatzki <[email protected]>

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/[email protected]/

> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_stream.c b/drivers/gp=
u/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(
> =20
>  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));
>  	}
> =20
>  	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.=20

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/g=
pu/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_sta=
te, const struct dc_plane
>   ***********************************************************************=
*******/
>  struct dc_plane_state *dc_create_plane_state(const struct dc *dc)
>  {
> -	struct dc_plane_state *plane_state =3D kvzalloc_obj(*plane_state,
> -							  GFP_ATOMIC);
> +	struct dc_plane_state *plane_state;
> +	DC_RUN_WITH_PREEMPTION_ENABLED(plane_state =3D kvzalloc_obj(*plane_stat=
e, 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().=20

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

> =20
>  	if (NULL =3D=3D 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?

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260727105059.7571=
[email protected]?part=3D1