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

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

Patch Review

The fix is conceptually correct — `migrate.cpages` after `migrate_vma_setup` counts folios, not base pages, so a single 2M THP would report cpages=1 while npages=512.

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

```c
+static int drm_pagemap_cpages(unsigned long *migrate_pfn, unsigned long npages)
+{
+	unsigned long i, cpages = 0;
```

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

**Minor note**: The `MIGRATE_PFN_COMPOUND` branch hardcodes `HPAGE_PMD_ORDER`:

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

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

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

---

---
Generated by Claude Code Patch Reviewer