Claude review: drm/panthor: Lazily allocate pages on mmap()

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

Patch Review

This patch defers page allocation from `mmap()` time to fault time. The fault handler is significantly reworked with a nonblocking fast path and a blocking slow path.

1. **`nonblocking_page_setup`**: Uses `dma_resv_trylock()` — returns `VM_FAULT_RETRY` if pages aren't allocated or lock is contended. This is correct for the fast path.

2. **`blocking_page_setup`**: Uses `dma_resv_lock_interruptible()`. If it fails:
   - With mmap lock held: returns `VM_FAULT_NOPAGE` (will retry)
   - Without mmap lock: returns `VM_FAULT_RETRY`

   Minor concern: when `dma_resv_lock_interruptible()` returns `-EINTR`, returning `VM_FAULT_NOPAGE` with `mmap_lock_held=true` seems correct (the MM will retry), but if `err == -EDEADLK` (shouldn't happen with NULL ctx), the behavior would be the same.

3. **mmap lock release pattern**: The pattern of calling `mmap_read_unlock()`, doing work, then returning `VM_FAULT_RETRY` is standard for VM fault handlers that need to sleep.

4. **`drm_gem_object_get/put` around blocking path**: Correctly prevents the BO from being freed while the mmap lock is released.

5. **`vm_open` simplification**: The old `panthor_gem_vm_open` asserted pages were present and took the resv lock. With lazy allocation, it's simplified to just `drm_gem_vm_open`. This makes sense — pages may not be allocated yet.

No issues.

---
Generated by Claude Code Patch Reviewer