linux-kernel - Re: [PATCH v3] drm/tilcdc: Fix removal actions in case of failed probe

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: <DEH3W0I9EBRB.16EYRXFT7K0ZS@bootlin.com>
Date: Mon, 24 Nov 2025 18:37:39 +0100
From: "Luca Ceresoli" <luca.ceresoli@...tlin.com>
To: "Kory Maincent" <kory.maincent@...tlin.com>
Cc: "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>, "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

Hi Köry,

On Fri Nov 21, 2025 at 11:24 AM CET, Kory Maincent wrote:
> On Wed, 19 Nov 2025 18:12:40 +0100
> "Luca Ceresoli" <luca.ceresoli@...tlin.com> wrote:
>
>> 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.
>
> Yes not sure either but as it was already present I let it here.
> Do you think I should remove it?

At a quick look at the component framework, it does not seem to
care. However you are fixing a bug, so it's fine if you leave
platform_set_drvdata() untouched out of caution.

>> 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.
>
> Yes indeed, but this won't be a fix as there is no real issue in the remove
> AFAIK.

Sure! Cleaning up tilcdc_fini() would be a cleanup, not a bugfix, so you
can do it in a separate series without affecting this bugfix patch.

Luca

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