Claude review: drm/pagemap: Correct cpages calculation for migrate_vma_setup

[Claude Code Review Bot <claude-review@example.com>]

Patch Review

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

**Observation — MIGRATE_PFN_COMPOUND without a page:**

```c
} else if (migrate_pfn[i] & MIGRATE_PFN_COMPOUND) {
    order = HPAGE_PMD_ORDER;
    cpages += 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 large folios that can't be directly referenced? It's a bit unusual — if there's no page, what does the compound flag mean? This seems like a defensive measure, but a comment explaining when this case occurs would help readability.

**Minor — 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`), the return type could be `unsigned long`.

---
Generated by Claude Code Patch Reviewer