Re: [PATCH 60/60] drm/plane: Remove reset

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Discarded return value of atomic_create_state() leads to leaked memory and NULL pointer dereference.
--

--- Patch [60]: [PATCH 60/60] drm/plane: Remove reset ---
commit 272441f81f14a41d0a23a7e99bf3963a3955d652
Author: Maxime Ripard <mripard@kernel.org>

    drm/plane: Remove reset
    
    All plane drivers now implement the atomic_create_state hook instead of
    the reset hook for initial state creation. The reset hook conflated
    initial state allocation at probe time with hardware and software reset
    during suspend/resume, making error handling difficult since it is not
    fallible.
    
    Remove the reset hook from struct drm_plane_funcs and the associated
    call in drm_mode_config_reset().

> diff --git a/drivers/gpu/drm/drm_mode_config.c b/drivers/gpu/drm/drm_mode_config.c
> index f432f485a914c..4b07189e3be5e 100644
> --- a/drivers/gpu/drm/drm_mode_config.c
> +++ b/drivers/gpu/drm/drm_mode_config.c
> @@ -289,9 +289,7 @@ void drm_mode_config_reset(struct drm_device *dev)
>  		drm_colorop_reset(colorop);
>  
>  	drm_for_each_plane(plane, dev) {
> -		if (plane->funcs->reset)
> -			plane->funcs->reset(plane);
> -		else if (plane->funcs->atomic_create_state)
> +		if (plane->funcs->atomic_create_state)
>  			drm_mode_config_plane_reset_with_create_state(plane);
>  	}

[Severity: High]
With the transition to atomic_create_state, is there a missing assignment for
AMDGPU displays during initialization?

In drm_mode_config_reset() above, the core handles the new hook by calling
drm_mode_config_plane_reset_with_create_state(), which properly assigns the
allocated state to plane->state.

However, AMDGPU does not call drm_mode_config_reset(). In
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c,
amdgpu_dm_plane_init() calls the new hook manually but discards the result:

	/* Create (reset) the plane state */
	if (plane->funcs->atomic_create_state)
		plane->funcs->atomic_create_state(plane);

Unlike the old reset hook which assigned plane->state internally (via
__drm_atomic_helper_plane_reset()), atomic_create_state() just returns
the new state pointer. Discarding this return value leaves plane->state as
NULL and leaks the allocated state.

Will this cause a NULL pointer dereference on AMD platforms later in the boot
process, such as during drm_client_modeset_probe(), when
atomic_duplicate_state() attempts to access plane->state?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260709-drm-no-more-plane-reset-v1-0-302d986fe5f0@kernel.org?part=60