Claude review: mm/memory: Fix spurious warning when unmapping device-private/exclusive pages

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

Patch Review

**Kernel fix (mm/memory.c):**

The one-line change is correct and well-placed:

```c
-		WARN_ON_ONCE(!vma_is_anonymous(vma));
+		WARN_ON_ONCE(!folio_test_anon(folio));
```

The `folio` variable is already in scope (declared at the top of the device-private/exclusive block), so this is safe. The fix aligns the unmap-path assertion with what `__migrate_device_pages()` actually enforces at migration time (see `mm/migrate_device.c:1203`):

```c
if (!folio_test_anon(folio) ||
    !folio_free_swap(folio)) {
    src_pfns[i] &= ~MIGRATE_PFN_MIGRATE;
    goto next;
}
```

The surrounding comment ("Both device private/exclusive mappings should only work with anonymous page") remains accurate — the invariant is about the folio being anonymous, not the VMA. The uffd-wp reasoning still holds since uffd-wp markers for anonymous folios are tracked via swap entries, independent of VMA type.

The Fixes tag (`999dad824c39e`) and `Cc: stable` are appropriate.

**Selftest (hmm-tests.c):**

The new `migrate_file_private` test correctly exercises the bug:
1. Creates a temp file via `hmm_create_file()`
2. Maps it `MAP_PRIVATE` (file-backed VMA, `vma_is_anonymous()` = false)
3. Writes to it (triggers CoW, `folio_test_anon()` becomes true)
4. Migrates to device private memory (succeeds because `folio_test_anon()` is checked)
5. `hmm_buffer_free()` calls `munmap()`, triggering `zap_nonpresent_ptes()` — where the old assertion would fire

The test follows the existing patterns (`file_read`, `migrate`) well.

**Minor nit:** The test leaks the file descriptor from `hmm_create_file()`. Since the file is `O_TMPFILE`, the data is cleaned up on process exit, but `close(fd)` should be called for correctness, especially in a long-running test harness. This is technically a pre-existing issue (the `file_read` test at line 847 has the same leak), but since this is new code, it's worth adding a `close(buffer->fd)` or `close(fd)` before `hmm_buffer_free()`. Alternatively, `hmm_buffer_free()` could be extended to close `buffer->fd` when it's not `-1`.

No other issues found.

---
Generated by Claude Code Patch Reviewer