Re: [PATCH v2] drm/gud: Ignore damage clips in full update mode

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] The iterator variable `connector_state` leaks out of `for_each_new_connector_in_state`, bypassing the fallback search.
--

commit 4deed33a0bafa9e2ff82e53d1da0f3130451d673
Author: Sophie D <patches@scd31.com>

drm/gud: Ignore damage clips in full update mode

When running in full update mode, previously small updates (such as
moving the mouse across the screen) would cause many full frames to be
generated. This would bog down the bus and lower the effective framerate
significantly - I was seeing a drop from 60 FPS to 2 FPS.

> diff --git a/drivers/gpu/drm/gud/gud_pipe.c b/drivers/gpu/drm/gud/gud_pipe.c
> index 5ef887d8485a3..3388fdc8ea7b5 100644
> --- a/drivers/gpu/drm/gud/gud_pipe.c
> +++ b/drivers/gpu/drm/gud/gud_pipe.c
> @@ -482,6 +482,9 @@ int gud_plane_atomic_check(struct drm_plane *plane,
>  	if (!new_plane_state->visible)
>  		return 0;
>  
> +	if (gdrm->flags & GUD_DISPLAY_FLAG_FULL_UPDATE)
> +		new_plane_state->ignore_damage_clips = true;
> +
>  	if (old_plane_state->rotation != new_plane_state->rotation)
>  		crtc_state->mode_changed = true;
>  

[Severity: High]
This isn't a bug introduced by this patch, but while reviewing
gud_plane_atomic_check(), I noticed an issue with the fallback search for
the connector.

Does connector_state bypass the fallback search here?

	for_each_new_connector_in_state(state, connector, connector_state, i) {
		if (connector_state->crtc)
			break;
	}

	/*
	 * DRM_IOCTL_MODE_OBJ_SETPROPERTY on the rotation property will not have
	 * the connector included in the state.
	 */
	if (!connector_state) {
		struct drm_connector_list_iter conn_iter;

If the loop finishes without finding a matching CRTC, connector_state retains
the pointer to the last evaluated connector rather than evaluating to NULL.
This happens because short-circuit evaluation prevents the macro's assignment
block from running on the final iteration.

Could this cause the driver to extract properties and the connector index from
an unrelated or disconnected connector and send them to the hardware device
during the atomic check phase, leading to hardware misconfiguration?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260910014910.8564-1-patches@scd31.com?part=1