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: mm/memory: Fix spurious warning when unmapping device-private/exclusive pages
Date: Tue, 05 May 2026 09:37:51 +1000
Message-ID: <review-patch1-20260501065116.2057242-1-apopple@nvidia.com>
In-Reply-To: <20260501065116.2057242-1-apopple@nvidia.com>
References: <20260501065116.2057242-1-apopple@nvidia.com> <20260501065116.2057242-1-apopple@nvidia.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

**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 a=
ssertion with what `__migrate_device_pages()` actually enforces at migratio=
n time (see `mm/migrate_device.c:1203`):

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

The surrounding comment ("Both device private/exclusive mappings should onl=
y work with anonymous page") remains accurate =E2=80=94 the invariant is ab=
out the folio being anonymous, not the VMA. The uffd-wp reasoning still hol=
ds 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()` =3D 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()`=
 =E2=80=94 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` te=
st at line 847 has the same leak), but since this is new code, it's worth a=
dding a `close(buffer->fd)` or `close(fd)` before `hmm_buffer_free()`. Alte=
rnatively, `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