Re: [PATCH] drm/amd/display: Shorten hdmi_frl_status_polling_workqueue

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Resource leak of hdmi_frl_status_polling_wq during module teardown or initialization failure.
- [High] NULL pointer dereference if hdmi_frl_status_polling_wq allocation fails.
--

commit b8f83563decd99d69977bc64fe3e67736687cb49
Author: Nathan Chancellor <nathan@kernel.org>
drm/amd/display: Shorten hdmi_frl_status_polling_workqueue

This commit shortens the name of the hdmi_frl_status_polling_wq workqueue
to prevent warnings about exceeding the maximum workqueue name length.

Fixes: 5c9b8b27a883 ("drm/amd/display: Tie FRL support into amdgpu_dm")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>

> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 8f80420e9f0b8..3cde7a456858c 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -2259,9 +2259,9 @@ static int amdgpu_dm_init(struct amdgpu_device *adev)
>  	}
>  	if (adev->dm.dc->caps.max_links > 0) {
>  		adev->dm.hdmi_frl_status_polling_wq =
> -			create_singlethread_workqueue("hdmi_frl_status_polling_workqueue");
> +			create_singlethread_workqueue("hdmi_frl_status_polling_wq");

[Severity: High]
This isn't a bug introduced by this patch, but does this workqueue get
leaked on driver unload?

Looking at amdgpu_dm_fini(), there doesn't seem to be a corresponding
destroy_workqueue() call for this specific workqueue. Does this mean every
time the driver is unloaded or initialization fails after this point, the
workqueue struct and its internal resources are leaked?

>  		if (!adev->dm.hdmi_frl_status_polling_wq)
> -			drm_err(adev_to_drm(adev), "failed to initialize hdmi_frl_status_polling_workqueue\n");
> +			drm_err(adev_to_drm(adev), "failed to initialize hdmi_frl_status_polling_wq\n");

[Severity: High]
This is also a pre-existing issue, but can an allocation failure here
cause a NULL pointer dereference later on?

Unlike other workqueues in this function that use a goto error path when
allocation fails, this just logs the error and continues. If it returns
NULL, wouldn't amdgpu_dm_commit_streams() trigger a kernel panic when it
subsequently calls queue_delayed_work() using this NULL pointer?

>  		adev->dm.hdmi_frl_status_polling_delay_ms = 200;
>  		INIT_DELAYED_WORK(&adev->dm.hdmi_frl_status_polling_work, hdmi_frl_status_polling_work);
>  	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260604-amdgpu-fix-wq_name_len-warning-v1-1-eb5415b45b27@kernel.org?part=1