Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] Closing a GEM object or MMU context during/after device unbind causes a kernel panic due to unclocked MMU register access. -- commit 78f80dbfd319f079f4898f5d8b2af5e44a1877d5 Author: Adrián Larumbe <[email protected]> drm/panfrost: Move shrinker initialization and unplug one level down This commit moves the initialization and cleanup of the GEM shrinker into the core GEM init and fini paths. It mimics the behavior seen in Panthor and removes an unnecessary config feature check. > diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c > b/drivers/gpu/drm/panfrost/panfrost_drv.c > --- a/drivers/gpu/drm/panfrost/panfrost_drv.c > +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c [ ... ] > @@ -1024,7 +1019,6 @@ static void panfrost_remove(struct platform_device > *pdev) > struct panfrost_device *pfdev = platform_get_drvdata(pdev); > > drm_dev_unregister(&pfdev->base); > - panfrost_gem_shrinker_cleanup(&pfdev->base); > > pm_runtime_get_sync(pfdev->base.dev); > pm_runtime_disable(pfdev->base.dev); [Severity: High] This is a pre-existing issue, but closing a GEM object or MMU context during or after device unbind can cause a kernel panic due to unclocked MMU register access. When a userspace process closes a DRM file descriptor concurrently with device unbind, it triggers panfrost_mmu_flush_range(). During unbind, pm_runtime_disable() is called here while the device is in the RPM_ACTIVE state. The status remains RPM_ACTIVE even after panfrost_clk_fini() turns off the hardware clocks. Because the status remains active, concurrent execution of panfrost_mmu_flush_range() evaluates to true: drivers/gpu/drm/panfrost/panfrost_mmu.c:panfrost_mmu_flush_range() { ... if (pm_runtime_active(pfdev->base.dev)) mmu_hw_do_operation(pfdev, mmu, iova, size, AS_COMMAND_FLUSH_PT); ... } The same vulnerability exists in context destruction during teardown: drivers/gpu/drm/panfrost/panfrost_mmu.c:panfrost_mmu_release_ctx() { ... if (pm_runtime_active(pfdev->base.dev)) panfrost_mmu_disable(pfdev, mmu->as); ... } Could this pm_runtime_disable() sequence leave the device vulnerable to a synchronous external abort on ARM when those powered-down registers are concurrently accessed? -- Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1
