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 13:55:14 +1000
Message-ID: <review-patch3-20260312192126.2024853-4-francois.dugast@intel.com>
In-Reply-To: <20260312192126.2024853-4-francois.dugast@intel.com>
References: <20260312192126.2024853-1-francois.dugast@intel.com> <20260312192126.2024853-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

**Good:** The commit message clearly explains the problem: `migrate_vma_set=
up` returns cpages as the count of entries (folios/pages), not the count of=
 base pages, so a single 2MB compound page returns cpages=3D1 but npages=3D=
512.

**Observation =E2=80=94 MIGRATE_PFN_COMPOUND without a page:**

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

This branch handles compound entries where `migrate_pfn_to_page()` returns =
NULL but the COMPOUND flag is set. This would be the case for PTE-mapped la=
rge folios that can't be directly referenced? It's a bit unusual =E2=80=94 =
if there's no page, what does the compound flag mean? This seems like a def=
ensive measure, but a comment explaining when this case occurs would help r=
eadability.

**Minor =E2=80=94 return type:** The function returns `int` but `cpages` is=
 `unsigned long`. This is fine in practice since npages won't overflow int,=
 but for consistency with the `npages` parameter type (`unsigned long`), th=
e return type could be `unsigned long`.

---
Generated by Claude Code Patch Reviewer