Claude review: lib: test_hmm: evict device pages on file close to avoid use-after-free

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

Patch Review

**Correctness concern — evicts ALL device chunks, not just this dmirror's pages:**

The release handler iterates over all `mdevice->devmem_chunks` and calls `dmirror_device_evict_chunk()` on each:

```c
if (mdevice->devmem_chunks) {
    for (i = 0; i < mdevice->devmem_count; i++) {
        struct dmirror_chunk *devmem =
            mdevice->devmem_chunks[i];
        dmirror_device_evict_chunk(devmem);
    }
}
```

This evicts **all** device private pages from the entire device, not just pages belonging to the closing dmirror instance. If multiple file descriptors (and thus multiple `dmirror` structs) are open on the same device simultaneously, closing one will evict pages that belong to other active dmirror instances. The `migrate_device_range()` call operates on physical PFN ranges and doesn't filter by owner.

In practice this is probably fine for a test driver (tests are sequential), but it's worth noting in the commit message or as a comment. The proper fix would filter pages by checking `zone_device_data` against the closing `dmirror`, but that's significantly more complex and probably overkill for a test module.

**Missing locking:** The `dmirror_device_remove_chunks()` function takes `mdevice->devmem_lock` and `mdevice->lock` when doing eviction, but the eviction in `dmirror_fops_release()` holds neither lock. `migrate_device_range()` likely handles its own synchronization, but the lack of `devmem_lock` around the `mdevice->devmem_chunks` / `mdevice->devmem_count` access is a potential TOCTOU issue if chunks could be added/removed concurrently.

**No NULL check on folio_alloc for compound pages:**

```c
if (src_pfns[i] & MIGRATE_PFN_COMPOUND) {
    dpage = folio_page(folio_alloc(GFP_HIGHUSER_MOVABLE,
                  order), 0);
}
```

If `folio_alloc()` returns NULL, `folio_page(NULL, 0)` will crash. The non-compound path uses `__GFP_NOFAIL` but the compound path doesn't. This is a pre-existing issue (the function was just moved), not introduced by this patch.

**Overall:** The fix is correct for the reported problem. The function move is clean — the code is identical.

---
Generated by Claude Code Patch Reviewer