Re: [PATCH v6 01/16] drm/panfrost: Move shrinker initialization and unplug one level down

[sashiko-bot@kernel.org]

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 <adrian.larumbe@collabora.com>

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/20260826-claude-fixes-v6-0-78119af409e7@collabora.com?part=1