[PATCH] drm/lima: call drm_mm_init() with a valid allocation range

[PATCH] drm/lima: call drm_mm_init() with a valid allocation range

[Henrik Grimler]

lima_vm_create() is currently run before va_start and va_end are set up,
meaning they are both 0. lima_vm_create() runs drm_mm_init() with them
as arguments for the allocator, and if DRM_DEBUG_MM is enabled the
DRM_MM_BUG_ON check in drm_mm_init then fires, as seen here on
exynos4412-odroid-u2:

[    1.736297] ------------[ cut here ]------------
[    1.740370] kernel BUG at drivers/gpu/drm/drm_mm.c:931!
[    1.745574] Internal error: Oops - BUG: 0 [#1] SMP ARM
[    1.750697] Modules linked in:
[    1.753734] CPU: 0 UID: 0 PID: 41 Comm: kworker/u16:1 Not tainted 7.0.10-postmarketos-exynos4 #11 PREEMPT
[    1.763372] Hardware name: Samsung Exynos (Flattened Device Tree)
[    1.769446] Workqueue: events_unbound deferred_probe_work_func
[    1.775261] PC is at drm_mm_init+0x9c/0xa4
[    1.779339] LR is at lima_vm_create+0x144/0x17c
[ ... ]

Fix the issue by moving the lima_vm_create() call after va_start and
va_end are set up.

Fixes: a1d2a6339961 ("drm/lima: driver for ARM Mali4xx GPUs")
Signed-off-by: Henrik Grimler <henrik.grimler@axis.com>
---
This is a low priority fix and can wait for v7.2, it does not cause
any real issues as far as I have seen: drm_mm_init() is re-run some
seconds after first run with correct parameters.
---
 drivers/gpu/drm/lima/lima_device.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/lima/lima_device.c b/drivers/gpu/drm/lima/lima_device.c
index 0bf7105c8748..7c873e62c16d 100644
--- a/drivers/gpu/drm/lima/lima_device.c
+++ b/drivers/gpu/drm/lima/lima_device.c
@@ -368,12 +368,6 @@ int lima_device_init(struct lima_device *ldev)
 	if (err)
 		goto err_out0;
 
-	ldev->empty_vm = lima_vm_create(ldev);
-	if (!ldev->empty_vm) {
-		err = -ENOMEM;
-		goto err_out1;
-	}
-
 	ldev->va_start = 0;
 	if (ldev->id == lima_gpu_mali450) {
 		ldev->va_end = LIMA_VA_RESERVE_START;
@@ -387,6 +381,12 @@ int lima_device_init(struct lima_device *ldev)
 	} else
 		ldev->va_end = LIMA_VA_RESERVE_END;
 
+	ldev->empty_vm = lima_vm_create(ldev);
+	if (!ldev->empty_vm) {
+		err = -ENOMEM;
+		goto err_out1;
+	}
+
 	ldev->iomem = devm_platform_ioremap_resource(pdev, 0);
 	if (IS_ERR(ldev->iomem)) {
 		dev_err(ldev->dev, "fail to ioremap iomem\n");

---
base-commit: c453c60fdba437f69209e027b418c4a24143605a
change-id: 20260529-lima-alloc-fix-2cd5408f6493

Best regards,
-- 
Henrik Grimler <henrik.grimler@axis.com>

Re: [PATCH] drm/lima: call drm_mm_init() with a valid allocation range

[Qiang Yu]

On Mon, Jun 1, 2026 at 8:04 PM Henrik Grimler <henrik.grimler@axis.com> wrote:
>
> lima_vm_create() is currently run before va_start and va_end are set up,
> meaning they are both 0. lima_vm_create() runs drm_mm_init() with them
> as arguments for the allocator, and if DRM_DEBUG_MM is enabled the
> DRM_MM_BUG_ON check in drm_mm_init then fires, as seen here on
> exynos4412-odroid-u2:
>
> [    1.736297] ------------[ cut here ]------------
> [    1.740370] kernel BUG at drivers/gpu/drm/drm_mm.c:931!
> [    1.745574] Internal error: Oops - BUG: 0 [#1] SMP ARM
> [    1.750697] Modules linked in:
> [    1.753734] CPU: 0 UID: 0 PID: 41 Comm: kworker/u16:1 Not tainted 7.0.10-postmarketos-exynos4 #11 PREEMPT
> [    1.763372] Hardware name: Samsung Exynos (Flattened Device Tree)
> [    1.769446] Workqueue: events_unbound deferred_probe_work_func
> [    1.775261] PC is at drm_mm_init+0x9c/0xa4
> [    1.779339] LR is at lima_vm_create+0x144/0x17c
> [ ... ]
>
> Fix the issue by moving the lima_vm_create() call after va_start and
> va_end are set up.
>
> Fixes: a1d2a6339961 ("drm/lima: driver for ARM Mali4xx GPUs")
> Signed-off-by: Henrik Grimler <henrik.grimler@axis.com>
> ---
> This is a low priority fix and can wait for v7.2, it does not cause
> any real issues as far as I have seen: drm_mm_init() is re-run some
> seconds after first run with correct parameters.

Reviewed-by: Qiang Yu <yuq825@gmail.com>

drm mm in the empty_vm is not used at all, so no issue caused by it.
drm mm of a real per app vm matters but they are initialized properly
after va_start/end set. In fact only the PDE page matters in empty_vm,
I should only create it instead of the full lima_vm.

> ---
>  drivers/gpu/drm/lima/lima_device.c | 12 ++++++------
>  1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/lima/lima_device.c b/drivers/gpu/drm/lima/lima_device.c
> index 0bf7105c8748..7c873e62c16d 100644
> --- a/drivers/gpu/drm/lima/lima_device.c
> +++ b/drivers/gpu/drm/lima/lima_device.c
> @@ -368,12 +368,6 @@ int lima_device_init(struct lima_device *ldev)
>         if (err)
>                 goto err_out0;
>
> -       ldev->empty_vm = lima_vm_create(ldev);
> -       if (!ldev->empty_vm) {
> -               err = -ENOMEM;
> -               goto err_out1;
> -       }
> -
>         ldev->va_start = 0;
>         if (ldev->id == lima_gpu_mali450) {
>                 ldev->va_end = LIMA_VA_RESERVE_START;
> @@ -387,6 +381,12 @@ int lima_device_init(struct lima_device *ldev)
>         } else
>                 ldev->va_end = LIMA_VA_RESERVE_END;
>
> +       ldev->empty_vm = lima_vm_create(ldev);
> +       if (!ldev->empty_vm) {
> +               err = -ENOMEM;
> +               goto err_out1;
> +       }
> +
>         ldev->iomem = devm_platform_ioremap_resource(pdev, 0);
>         if (IS_ERR(ldev->iomem)) {
>                 dev_err(ldev->dev, "fail to ioremap iomem\n");
>
> ---
> base-commit: c453c60fdba437f69209e027b418c4a24143605a
> change-id: 20260529-lima-alloc-fix-2cd5408f6493
>
> Best regards,
> --
> Henrik Grimler <henrik.grimler@axis.com>
>

Claude review: drm/lima: call drm_mm_init() with a valid allocation range

[Claude Code Review Bot]

Patch Review

**Bug analysis is correct.** `lima_vm_create()` at line 371 calls `drm_mm_init(&vm->mm, dev->va_start, dev->va_end - dev->va_start)` while both values are still 0, which triggers the `DRM_MM_BUG_ON` in `drm_mm_init()` when `DRM_DEBUG_MM` is enabled.

**Error handling bug — dlbu_cpu leak on mali450:**

After the patch, the initialization order becomes:

1. `va_start` / `va_end` setup
2. `dlbu_cpu` DMA allocation (mali450 only)
3. `lima_vm_create()`

If `lima_vm_create()` fails at step 3, the patch does:

```c
+	ldev->empty_vm = lima_vm_create(ldev);
+	if (!ldev->empty_vm) {
+		err = -ENOMEM;
+		goto err_out1;
+	}
```

But `goto err_out1` skips `err_out3` (which frees `dlbu_cpu`) and `err_out2` (which puts the VM). The cleanup labels are:

```c
err_out3:
	if (ldev->dlbu_cpu)
		dma_free_wc(ldev->dev, LIMA_PAGE_SIZE,
			    ldev->dlbu_cpu, ldev->dlbu_dma);
err_out2:
	lima_vm_put(ldev->empty_vm);
err_out1:
	lima_regulator_fini(ldev);
```

On mali450, `dlbu_cpu` was successfully allocated at step 2, so jumping to `err_out1` leaks that DMA allocation. The correct goto target should be `err_out3`, not `err_out1`. Going through `err_out3` will free `dlbu_cpu` if allocated, and `err_out2` is safe because `lima_vm_put()` handles NULL:

```c
static inline void lima_vm_put(struct lima_vm *vm)
{
	if (vm)
		kref_put(&vm->refcount, lima_vm_release);
}
```

**The existing `dlbu_cpu` failure goto is technically safe but sloppy.** The dlbu_cpu allocation failure path retains `goto err_out2`, which calls `lima_vm_put(ldev->empty_vm)` on a not-yet-created VM. This works only because `lima_vm_put()` has a NULL check and `ldev` is zero-initialized. It would be cleaner to change this to `goto err_out1`, though it's not a correctness bug.

**Behavioral change on mali450 — DLBU mapping in empty_vm:**

`lima_vm_create()` contains:
```c
if (dev->dlbu_cpu) {
	int err = lima_vm_map_page(
		vm, dev->dlbu_dma, LIMA_VA_RESERVE_DLBU);
```

In the original code, `dlbu_cpu` was NULL when `lima_vm_create()` ran, so this mapping was skipped for the `empty_vm`. After the patch, `dlbu_cpu` is allocated before `lima_vm_create()`, so the DLBU page is now mapped in the `empty_vm`. This is likely the correct behavior (and the original omission was an unintentional consequence of the wrong ordering), but the commit message does not mention this change.

**Suggested fix:** Change the `lima_vm_create()` failure goto from `err_out1` to `err_out3`:

```c
	ldev->empty_vm = lima_vm_create(ldev);
	if (!ldev->empty_vm) {
		err = -ENOMEM;
-		goto err_out1;
+		goto err_out3;
	}
```

And optionally clean up the dlbu_cpu failure goto:

```c
	if (!ldev->dlbu_cpu) {
		err = -ENOMEM;
-		goto err_out2;
+		goto err_out1;
	}
```

---
Generated by Claude Code Patch Reviewer

Claude review: drm/lima: call drm_mm_init() with a valid allocation range

[Claude Code Review Bot]

Overall Series Review

Subject: drm/lima: call drm_mm_init() with a valid allocation range
Author: Henrik Grimler <henrik.grimler@axis.com>
Patches: 2
Reviewed: 2026-06-04T14:10:22.015325

---

This is a single-patch fix for a real bug in the lima driver where `lima_vm_create()` is called before `ldev->va_start` and `ldev->va_end` are initialized, resulting in `drm_mm_init()` being called with a zero-size range. With `DRM_DEBUG_MM` enabled, this triggers a `BUG_ON`. The diagnosis and fix direction are correct — moving `lima_vm_create()` after the VA range setup is the right thing to do.

However, **the patch introduces a resource leak on the error path for mali450 devices**. The error goto labels are not updated to match the new initialization order, so a `lima_vm_create()` failure on mali450 will leak the `dlbu_cpu` DMA allocation.

---
Generated by Claude Code Patch Reviewer