Claude review: mm/mmu_notifier: Allow two-pass struct mmu_interval_notifiers

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

Patch Review

This is the core mm infrastructure change. The design uses `invalidate_start` + `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 `invalidate` 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 — duplicated dispatching logic:**

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

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

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

**Concern — mn_itree_invalidate -EAGAIN path calls finish on partial 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_passes)`. This means `invalidate_finish` callbacks will be invoked for notifiers that were already processed, while the iteration was aborted mid-way:

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

This is actually correct behavior — the finish pass must still run for all notifiers that *did* successfully start, to complete their work. The comment should perhaps clarify this is intentional.

**Minor:** The `llist_reverse_order()` call in `mn_itree_finish_pass` ensures 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 refinements are welcome.

---

---
Generated by Claude Code Patch Reviewer