From mboxrd@z Thu Jan  1 00:00:00 1970
From: Claude Code Review Bot <claude-review@example.com>
To: dri-devel-reviews@example.com
Subject: Claude review: drm/pagemap: Correct cpages calculation for migrate_vma_setup
Date: Fri, 13 Mar 2026 14:02:32 +1000
Message-ID: <review-patch3-20260312151726.1779566-4-francois.dugast@intel.com>
In-Reply-To: <20260312151726.1779566-4-francois.dugast@intel.com>
References: <20260312151726.1779566-1-francois.dugast@intel.com> <20260312151726.1779566-4-francois.dugast@intel.com>
X-Mailer: Claude Code Patch Reviewer
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Patch Review

The fix is conceptually correct =E2=80=94 `migrate.cpages` after `migrate_v=
ma_setup` counts folios, not base pages, so a single 2M THP would report cp=
ages=3D1 while npages=3D512.

**Issue: Return type mismatch.** The function returns `int` but the interna=
l counter `cpages` is `unsigned long`, and it's compared against `npages` w=
hich is also `unsigned long`:

```c
+static int drm_pagemap_cpages(unsigned long *migrate_pfn, unsigned long np=
ages)
+{
+	unsigned long i, cpages =3D 0;
```

The return should be `unsigned long` to avoid potential truncation on 64-bi=
t systems with very large migration ranges. In practice this may never trig=
ger (migrations are bounded), but it's technically incorrect and easy to fi=
x.

**Minor note**: The `MIGRATE_PFN_COMPOUND` branch hardcodes `HPAGE_PMD_ORDE=
R`:

```c
+		} else if (migrate_pfn[i] & MIGRATE_PFN_COMPOUND) {
+			order =3D HPAGE_PMD_ORDER;
```

This assumes compound pages are always PMD-sized (2MB on x86). This is curr=
ently true for the THP migration path, but if other compound orders are eve=
r supported, this would need updating. A comment noting this assumption wou=
ld be helpful.

**Verdict: Return type should be `unsigned long`. Otherwise correct.**

---

---
Generated by Claude Code Patch Reviewer