lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <DECU85YFDJFQ.51DNK1JF0CQ4@bootlin.com>
Date: Wed, 19 Nov 2025 18:12:40 +0100
From: "Luca Ceresoli" <luca.ceresoli@...tlin.com>
To: "Kory Maincent" <kory.maincent@...tlin.com>, "Maxime Ripard"
 <mripard@...nel.org>, "Douglas Anderson" <dianders@...omium.org>, "Tomi
 Valkeinen" <tomi.valkeinen@...asonboard.com>,
 <dri-devel@...ts.freedesktop.org>, <linux-kernel@...r.kernel.org>
Cc: "Bajjuri Praneeth" <praneeth@...com>, "Louis Chauvet"
 <louis.chauvet@...tlin.com>, <stable@...r.kernel.org>,
 <thomas.petazzoni@...tlin.com>, "Jyri Sarha" <jyri.sarha@....fi>, "Maarten
 Lankhorst" <maarten.lankhorst@...ux.intel.com>, "Thomas Zimmermann"
 <tzimmermann@...e.de>, "David Airlie" <airlied@...il.com>, "Simona Vetter"
 <simona@...ll.ch>
Subject: Re: [PATCH v3] drm/tilcdc: Fix removal actions in case of failed
 probe

Hello Köry,

On Tue Nov 18, 2025 at 2:38 PM CET, Kory Maincent wrote:
> From: "Kory Maincent (TI.com)" <kory.maincent@...tlin.com>
>
> The drm_kms_helper_poll_fini() and drm_atomic_helper_shutdown() helpers
> should only be called when the device has been successfully registered.
> Currently, these functions are called unconditionally in tilcdc_fini(),
> which causes warnings during probe deferral scenarios.
>
> [    7.972317] WARNING: CPU: 0 PID: 23 at drivers/gpu/drm/drm_atomic_state_helper.c:175 drm_atomic_helper_crtc_duplicate_state+0x60/0x68
> ...
> [    8.005820]  drm_atomic_helper_crtc_duplicate_state from drm_atomic_get_crtc_state+0x68/0x108
> [    8.005858]  drm_atomic_get_crtc_state from drm_atomic_helper_disable_all+0x90/0x1c8
> [    8.005885]  drm_atomic_helper_disable_all from drm_atomic_helper_shutdown+0x90/0x144
> [    8.005911]  drm_atomic_helper_shutdown from tilcdc_fini+0x68/0xf8 [tilcdc]
> [    8.005957]  tilcdc_fini [tilcdc] from tilcdc_pdev_probe+0xb0/0x6d4 [tilcdc]
>
> Fix this by rewriting the failed probe cleanup path using the standard
> goto error handling pattern, which ensures that cleanup functions are
> only called on successfully initialized resources. Additionally, remove
> the now-unnecessary is_registered flag.
>
> Cc: stable@...r.kernel.org
> Fixes: 3c4babae3c4a ("drm: Call drm_atomic_helper_shutdown() at shutdown/remove time for misc drivers")
> Signed-off-by: Kory Maincent (TI.com) <kory.maincent@...tlin.com>

Except for the bug reported by the kernel test robot, this patch looks
good to me. Just a couple thoughts, below.

> @@ -372,16 +371,34 @@ static int tilcdc_init(const struct drm_driver *ddrv, struct device *dev)
>
>  	ret = drm_dev_register(ddev, 0);
>  	if (ret)
> -		goto init_failed;
> -	priv->is_registered = true;
> +		goto stop_poll;
>
>  	drm_client_setup_with_color_mode(ddev, bpp);
>
>  	return 0;
>
> -init_failed:
> -	tilcdc_fini(ddev);
> +stop_poll:
> +	drm_kms_helper_poll_fini(ddev);
> +	tilcdc_irq_uninstall(ddev);
> +unbind_component:
> +	if (priv->is_componentized)
> +		component_unbind_all(dev, ddev);
> +unregister_cpufreq_notif:
> +#ifdef CONFIG_CPU_FREQ
> +	cpufreq_unregister_notifier(&priv->freq_transition,
> +				    CPUFREQ_TRANSITION_NOTIFIER);
> +#endif
> +destroy_crtc:
> +	tilcdc_crtc_destroy(priv->crtc);
> +disable_pm:
> +	pm_runtime_disable(dev);
> +	clk_put(priv->clk);
> +free_wq:
> +	destroy_workqueue(priv->wq);
> +put_drm:
>  	platform_set_drvdata(pdev, NULL);

I'm not 100% sure this is needed, but perhaps it is because of the
component framework being used.

If it is needed, then shouldn't it be present in tilcdc_fini() as well?

> +	ddev->dev_private = NULL;
> +	drm_dev_put(ddev);
>
>  	return ret;
>  }

About tilcdc_fini(), I think it can be itself cleaned up a lot (in another patch). Basically
it should do the same thing (almost) that are here below the 'return 0'
line, and in the same order. Now the list of actions is auite different and
the order is very different.

Luca

--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ