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 <[email protected]> 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 <[email protected]> > 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-eb5415b45...@kernel.org?part=1
