Re: [PATCH v2 1/6] drm/msm: serialise framebuffer pin state

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Initialization order vulnerability: mutex and refcount initialized after object is globally visible.
--

commit 43edb96a02a3e020c9ba63b15f602a74d5eb759f
Author: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>

drm/msm: serialise framebuffer pin state

This commit introduces a mutex to serialize framebuffer pin states, 
resolving an issue where parallel prepare and cleanup callbacks could 
leave a plane programmed with a NULL base address.

> diff --git a/drivers/gpu/drm/msm/msm_fb.c b/drivers/gpu/drm/msm/msm_fb.c
> --- a/drivers/gpu/drm/msm/msm_fb.c
> +++ b/drivers/gpu/drm/msm/msm_fb.c

[ ... ]

> @@ -206,6 +227,7 @@ msm_framebuffer_init(struct drm_device *dev, const struct drm_format_info *info,
>  	}
>  
>  	refcount_set(&msm_fb->dirtyfb, 1);
> +	mutex_init(&msm_fb->lock);

[Severity: High]
Since drm_framebuffer_init() is called just before this block and registers
the object in the DRM core IDR, the framebuffer becomes immediately visible
to userspace.

If userspace guesses the assigned framebuffer ID and concurrently issues an
atomic commit ioctl, could msm_framebuffer_prepare() execute and call
mutex_lock(&msm_fb->lock) before mutex_init() finishes here?

Could this race lead to memory corruption or deadlocks by clobbering the
mutex state? Would it be safer to move the mutex initialization to before
the drm_framebuffer_init() call?

>  
>  	drm_dbg_state(dev, "create: FB ID: %d (%p)\n", fb->base.id, fb);
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260908-fd-kms-fix-smmu-v2-0-9391815742a8@oss.qualcomm.com?part=1