Claude review: drm/xe/userptr: Convert invalidation to two-pass MMU notifier

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

Patch Review

This converts the xe userptr notifier from a single `invalidate` callback to the new `invalidate_start`/`invalidate_finish` two-pass model.

**BUG — static local variable in `xe_vma_userptr_force_invalidate`:**

```c
void xe_vma_userptr_force_invalidate(struct xe_userptr_vma *uvma)
{
	static struct mmu_interval_notifier_finish *finish;
```

This declares `finish` as `static`, meaning it's shared across all calls to this function. This is almost certainly wrong — it should be a plain local variable. Using `static` here would cause data races if this function were ever called concurrently (even though it's under `CONFIG_DRM_XE_USERPTR_INVAL_INJECT` and may currently be single-threaded in testing paths, `static` is still incorrect). Should be:

```c
	struct mmu_interval_notifier_finish *finish;
```

**Design observation — `finish_inuse` flag:**

The `finish_inuse` bool is used to prevent two concurrent invalidations from both trying to use the embedded `struct mmu_interval_notifier_finish`. When `finish_inuse` is set, the second caller falls back to the synchronous single-pass path. This is a pragmatic approach that avoids dynamic allocation.

However, the lock protection for `finish_inuse` should be reviewed carefully. It's documented as:
```
Protected by struct xe_vm::svm.gpusvm.notifier_lock in write mode
alternatively by the same lock in read mode *and* the vm resv held.
```

In `xe_vma_userptr_invalidate_start`, the notifier_lock is held in write mode when `xe_vma_userptr_invalidate_pass1` reads and sets `finish_inuse`, so that's correct. In `xe_vma_userptr_invalidate_finish`, the notifier_lock is also taken in write mode, so clearing `finish_inuse` via `xe_vma_userptr_do_inval(vm, uvma, true)` is also correct.

**Locking assertion `xe_userptr_assert_in_notifier`:**

```c
static void xe_userptr_assert_in_notifier(struct xe_vm *vm)
{
	lockdep_assert(lockdep_is_held_type(&vm->svm.gpusvm.notifier_lock, 0) ||
		       (lockdep_is_held(&vm->lock) &&
			lockdep_is_held_type(&vm->svm.gpusvm.notifier_lock, 1) &&
			dma_resv_held(xe_vm_resv(vm))));
}
```

This asserts either: notifier_lock in write mode, OR (vm->lock held AND notifier_lock in read mode AND resv held). This matches the documented locking for the state members and looks correct.

**Minor nit:** The `xe_vma_userptr_do_inval` function unconditionally does `dma_resv_wait_timeout` with `MAX_SCHEDULE_TIMEOUT` and a non-blockable `false` parameter. This was inherited from the original code but it means this path always sleeps. The `mmu_notifier_range_blockable` check happens earlier in `xe_vma_userptr_invalidate_start`, which returns `false` if non-blockable. So this is fine.

Overall: **One bug (static variable), otherwise looks correct.**

---

---
Generated by Claude Code Patch Reviewer