Re: [PATCH v6 12/28] drm/mode-config: Read out hardware state in drm_mode_config_create_state

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] drm: missing state initialization fallback after successful SRO readout
--

commit 82595be49b2239429ccad442f233b1b0663939a4
Author: Maxime Ripard <mripard@kernel.org>

drm/mode-config: Read out hardware state in drm_mode_config_create_state

This commit updates drm_mode_config_create_initial_state() to populate
initial state from hardware using the atomic_sro_readout_state hook when
available, falling back to creating a pristine state otherwise.

> diff --git a/drivers/gpu/drm/drm_mode_config.c b/drivers/gpu/drm/drm_mode_config.c
> index 48a56f23dadbb..80d3fc511db5a 100644
> --- a/drivers/gpu/drm/drm_mode_config.c
> +++ b/drivers/gpu/drm/drm_mode_config.c

[ ... ]

> +int drm_mode_config_create_initial_state(struct drm_device *dev)
> +{
> +	int ret;
> +
> +	if (dev->mode_config.funcs->atomic_sro_readout_state) {
> +		ret = dev->mode_config.funcs->atomic_sro_readout_state(dev);
> +		if (!ret)
> +			return 0;

[Severity: High]
Does this early return bypass fallback state creation for objects not
handled by the SRO readout?

If atomic_sro_readout_state() succeeds and returns 0, the function returns
immediately and skips the subsequent call to drm_mode_config_create_state().

Any registered KMS objects that aren't populated by the driver's SRO
readout hook (such as drm_colorop objects or dormant planes) will be left
with a NULL state pointer. Because the DRM atomic framework strictly requires
a non-NULL state for all registered objects, won't this lead to a NULL
pointer dereference when operations like drm_atomic_helper_colorop_duplicate_state()
are called during the first atomic commit?

> +	}
> +
> +	return drm_mode_config_create_state(dev);
> +}
>  EXPORT_SYMBOL(drm_mode_config_create_initial_state);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261015-drm-state-readout-v6-0-6cc02cd10998@kernel.org?part=12