Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] Kernel panics in common KMS teardown path due to unconditional dereference of partially-initialized structures on early probe failures. -- --- Patch [1]: [PATCH] drm/msm: don't tear down KMS twice when KMS init fails --- commit dccb630956dd40369b4b75f78b147548c8331788 Author: Dmitry Baryshkov <[email protected]> drm/msm: don't tear down KMS twice when KMS init fails This commit removes the local KMS teardown from the mdp4 and mdp5 error paths. It instead relies on the common msm_drm_kms_uninit() path to handle cleanup on failure, preventing a use-after-free crash. > diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c > b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c > --- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c > +++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c > @@ -398,7 +398,7 @@ static int mdp4_kms_init(struct drm_device *dev) > ret = mdp_kms_init(&mdp4_kms->base, &kms_funcs); > if (ret) { > DRM_DEV_ERROR(dev->dev, "failed to init kms\n"); > - goto fail; > + return ret; > } [Severity: High] This is a pre-existing issue, but by delegating all cleanup to the common path on early failures, do we risk kernel panics from dereferencing uninitialized pointers? If mdp_kms_init() fails here, msm_drm_kms_uninit() will be called to clean up. However, if kms->wq was never allocated, won't flush_workqueue(kms->wq) trigger a panic inside __flush_workqueue() when it attempts to dereference the workqueue? Similarly, if initialization fails before kms->funcs is populated, could msm_irq_uninstall() trigger a NULL pointer dereference when executing kms->funcs->irq_uninstall(kms)? Additionally, when kms->funcs->destroy(kms) eventually calls mdp4_destroy(), would this unconditionally dereference mdp4_kms->dev->dev, where mdp4_kms->dev remains NULL because mdp_kms_init() failed? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
