public inbox for drm-ai-reviews@public-inbox.freedesktop.org
 help / color / mirror / Atom feed
From: Claude Code Review Bot <claude-review@example.com>
To: dri-devel-reviews@example.com
Subject: Claude review: lib/test_hmm: add a new testcase for the migrate on fault
Date: Mon, 25 May 2026 16:46:28 +1000	[thread overview]
Message-ID: <review-patch5-20260525050830.100254-6-mpenttil@redhat.com> (raw)
In-Reply-To: <20260525050830.100254-6-mpenttil@redhat.com>

Patch Review

**UAPI and testing concerns.**

1. **UAPI ioctl number renumbering is an ABI break:**
   ```c
   -#define HMM_DMIRROR_MIGRATE_TO_SYS    _IOWR('H', 0x03, ...)
   +#define HMM_DMIRROR_MIGRATE_ON_FAULT_TO_DEV _IOWR('H', 0x03, ...)
   +#define HMM_DMIRROR_MIGRATE_TO_SYS    _IOWR('H', 0x04, ...)
   ```
   All existing ioctls from 0x03 onward are renumbered. While this is a test driver (not general UAPI), any existing test binary compiled against the old headers will silently call the wrong ioctl. The new ioctl should be appended at the end (0x09) rather than inserted in the middle.

2. **`do_fault_and_migrate()` doesn't check `dmirror_range_fault()` return value before proceeding:**
   ```c
   ret = dmirror_range_fault(dmirror, range);
   pr_debug("Migrating from sys mem to device mem\n");
   migrate_hmm_range_setup(range);
   dmirror_migrate_alloc_and_copy(migrate, dmirror);
   ```
   If `dmirror_range_fault()` fails, the code continues to call `migrate_hmm_range_setup()` and the full migration sequence. The `ret` value is captured but not checked before proceeding.

3. **`dmirror_range_fault()` skips `mmap_read_lock` when migrating** but the `mmap_read_lock` is taken in the caller `do_fault_and_migrate()`. In `dmirror_range_fault()`:
   ```c
   if (!migrate) {
       mmap_read_lock(mm);
       ret = hmm_range_fault(range);
       mmap_read_unlock(mm);
   } else {
       ret = hmm_range_fault(range);
   }
   ```
   And in `do_fault_and_migrate()`:
   ```c
   mmap_read_lock(dmirror->notifier.mm);
   ret = dmirror_range_fault(dmirror, range);
   ...
   mmap_read_unlock(dmirror->notifier.mm);
   ```
   This is correct but the v10→v11 changelog says "Fix nested mmap_read_lock in test suite", so this was recently fixed. The fix looks correct — the lock is held across the entire fault+migrate sequence, which is required.

4. **Stack-allocated arrays** with fixed size:
   ```c
   unsigned long src_pfns[PFNS_ARRAY_SIZE] = { 0 };  // 64 entries = 64 * 8 = 512 bytes
   unsigned long dst_pfns[PFNS_ARRAY_SIZE] = { 0 };   // another 512 bytes
   ```
   1KB on the kernel stack is within limits but worth noting. The `range.hmm_pfns = src_pfns` reuses the same array for both HMM pfns and migrate src pfns, which is correct since `migrate_hmm_range_setup()` converts in-place.

5. **The selftest `hmm_migrate_on_fault` only tests the happy path** — anonymous private pages that are already present (initialized before migration). The cover letter's motivation is about migrating *non-present* pages, but the test doesn't cover that case (it writes to pages first, making them present). Adding a test that mmaps but doesn't touch the pages before migrating would better validate the stated goal.

---
Generated by Claude Code Patch Reviewer

  reply	other threads:[~2026-05-25  6:46 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-25  5:08 [PATCH v11 0/5] Migrate on fault for device pages mpenttil
2026-05-25  5:08 ` [PATCH v11 1/5] mm/Kconfig: changes for migrate " mpenttil
2026-05-25  6:46   ` Claude review: " Claude Code Review Bot
2026-05-25  5:08 ` [PATCH v11 2/5] mm: Add helper to convert HMM pfn to migrate pfn mpenttil
2026-05-25  6:46   ` Claude review: " Claude Code Review Bot
2026-05-25  5:08 ` [PATCH v11 3/5] mm/hmm: do the plumbing for HMM to participate in migration mpenttil
2026-05-25  6:46   ` Claude review: " Claude Code Review Bot
2026-05-25  5:08 ` [PATCH v11 4/5] mm: setup device page migration in HMM pagewalk mpenttil
2026-05-25  6:46   ` Claude review: " Claude Code Review Bot
2026-05-25  5:08 ` [PATCH v11 5/5] lib/test_hmm: add a new testcase for the migrate on fault mpenttil
2026-05-25  6:46   ` Claude Code Review Bot [this message]
2026-05-25  6:46 ` Claude review: Migrate on fault for device pages Claude Code Review Bot
  -- strict thread matches above, loose matches on Subject: below --
2026-05-25  8:45 [PATCH v12 0/5] " mpenttil
2026-05-25  8:45 ` [PATCH v12 5/5] lib/test_hmm: add a new testcase for the migrate on fault mpenttil
2026-05-25 21:29   ` Claude review: " Claude Code Review Bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=review-patch5-20260525050830.100254-6-mpenttil@redhat.com \
    --to=claude-review@example.com \
    --cc=dri-devel-reviews@example.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox