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/mmu_notifier: Allow two-pass struct mmu_interval_notifiers
Date: Wed, 04 Mar 2026 07:09:16 +1000
Message-ID: <review-patch1-20260303133409.11609-2-thomas.hellstrom@linux.intel.com>
In-Reply-To: <20260303133409.11609-2-thomas.hellstrom@linux.intel.com>
References: <20260303133409.11609-1-thomas.hellstrom@linux.intel.com> <20260303133409.11609-2-thomas.hellstrom@linux.intel.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

This is the core mm infrastructure change. The design uses `invalidate_star=
t` + `invalidate_finish` callbacks in the ops struct, with a lockless list =
to collect finish entries during the interval tree walk.

**Positive aspects:**
- Clean separation: drivers that don't need two-pass are unaffected (the `i=
nvalidate` callback remains)
- Using a lockless list (`llist`) to avoid a second interval tree walk is a=
 good optimization
- The `WARN_ON_ONCE` for `invalidate_start` without `invalidate_finish` is =
a useful safety check (added per Matt Brost's v3 review)
- Good documentation in the `struct mmu_interval_notifier_finish` kerneldoc=
 about GFP_NOWAIT allocation considerations

**Concern =E2=80=94 duplicated dispatching logic:**

The same if/else dispatching logic between `invalidate_start` and `invalida=
te` is duplicated in both `mn_itree_release` and `mn_itree_invalidate`:

```c
if (interval_sub->ops->invalidate_start) {
    struct mmu_interval_notifier_finish *finish =3D NULL;
    ret =3D interval_sub->ops->invalidate_start(..., &finish);
    if (ret && finish) {
        finish->notifier =3D interval_sub;
        __llist_add(&finish->link, &finish_passes);
    }
} else {
    ret =3D interval_sub->ops->invalidate(interval_sub, ...);
}
```

This is an exact copy-paste across both functions. Consider extracting a he=
lper like `mn_itree_inv_call()` to reduce the duplication. This is a minor =
style nit, not a blocker.

**Concern =E2=80=94 mn_itree_invalidate -EAGAIN path calls finish on partia=
l set:**

In `mn_itree_invalidate`, when a non-blockable callback returns false, the =
code breaks out of the loop but still calls `mn_itree_finish_pass(&finish_p=
asses)`. This means `invalidate_finish` callbacks will be invoked for notif=
iers that were already processed, while the iteration was aborted mid-way:

```c
if (!ret) {
    if (WARN_ON(mmu_notifier_range_blockable(range)))
        continue;
    err =3D -EAGAIN;
    break;
}
```
followed by:
```c
mn_itree_finish_pass(&finish_passes);
if (err)
    mn_itree_inv_end(subscriptions);
```

This is actually correct behavior =E2=80=94 the finish pass must still run =
for all notifiers that *did* successfully start, to complete their work. Th=
e comment should perhaps clarify this is intentional.

**Minor:** The `llist_reverse_order()` call in `mn_itree_finish_pass` ensur=
es FIFO ordering for the finish callbacks (matching the iteration order of =
the tree walk). This is a nice touch for deterministic behavior.

Overall: **Looks correct.** The WARN_ON_ONCE validation and the v2/v3 refin=
ements are welcome.

---

---
Generated by Claude Code Patch Reviewer