Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] MSM VM Lazy Initialization Violation: Direct access to lazily initialized ctx->vm without accessor. -- commit 1e90d5d8db7bb987e468148877a0109dc4324252 Author: Rob Clark <[email protected]> drm/msm: Validate lazy VM is created in GEM_SUBMIT This commit adds a NULL check for the context VM in the GEM_SUBMIT ioctl to prevent a null pointer exception when submitting before any buffer objects are mapped. > diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c > b/drivers/gpu/drm/msm/msm_gem_submit.c > index 26ea8a28be474..af564acf1f0df 100644 > --- a/drivers/gpu/drm/msm/msm_gem_submit.c > +++ b/drivers/gpu/drm/msm/msm_gem_submit.c > @@ -572,7 +572,7 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void > *data, > if (args->pad) > return -EINVAL; > > - if (to_msm_vm(ctx->vm)->unusable) > + if (ctx->vm && to_msm_vm(ctx->vm)->unusable) [Severity: High] This is a pre-existing issue, but should this code use the msm_context_vm() accessor instead of directly accessing ctx->vm here in msm_ioctl_gem_submit? According to the DRM subsystem guidelines, accessing ctx->vm directly in ioctl entry points before the VM is guaranteed to exist can be unsafe. Because ctx->vm is initialized lazily and published without memory barriers, a concurrent VM initialization could cause this unlocked read to observe a non-NULL pointer but read uninitialized memory for the unusable field. Might this lead to spurious EPIPE failures for valid submits? > return UERR(EPIPE, dev, "context is unusable"); > > /* for now, we just have 3d pipe.. eventually this would need to -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
