Claude review: fbdev: defio: Disconnect deferred I/O from the lifetime of struct fb_info

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

Patch Review

This is the core fix, tagged with `Cc: stable` back to v2.6.22. It introduces `struct fb_deferred_io_state` with kref-based lifetime management, decoupled from `struct fb_info`.

**Key design decisions (all good):**

- VMAs now store `fbdefio_state` in `vm_private_data` instead of `info`, and hold a kref reference via `vm_open`/`vm_close` ops.
- The state lock replaces `fbdefio->lock` for protecting the pageref list.
- Fault and mkwrite handlers check `fbdefio_state->info != NULL` under the lock, returning `VM_FAULT_SIGBUS` when the device is gone.

**Concern: race between schedule_delayed_work and cleanup**

In `fb_deferred_io_track_page()`, after unlocking the state mutex:

```c
mutex_unlock(&fbdefio_state->lock);

/* come back after delay to process the deferred IO */
schedule_delayed_work(&info->deferred_work, fbdefio->delay);
```

At this point `info` is a local copy obtained under the lock, but the lock is no longer held. A concurrent `fb_deferred_io_cleanup()` could proceed through:

```c
fb_deferred_io_lastclose(info);    /* cancel_delayed_work_sync */
info->fbdefio_state = NULL;
mutex_lock(&fbdefio_state->lock);
fbdefio_state->info = NULL;
mutex_unlock(&fbdefio_state->lock);
fb_deferred_io_state_put(fbdefio_state);
kvfree(info->pagerefs);
```

If cleanup's `cancel_delayed_work_sync` runs *before* thread A's `schedule_delayed_work`, the work gets re-queued on potentially soon-to-be-freed `info`. When the work fires, `fb_deferred_io_work` does `info->fbdefio_state` which could be NULL.

This is a very narrow window and is essentially pre-existing (the old code had the same pattern with `fbdefio->lock`), so it's not a regression. But if you wanted to close it, one option would be to have `fb_deferred_io_work` check `fbdefio_state->info` under the lock before proceeding, and to ensure `info->fbdefio_state` is not set to NULL before the lock/NULL/unlock sequence. Alternatively, moving `schedule_delayed_work` inside the lock would narrow (but not fully eliminate) the window.

**Minor nit:** In `fb_deferred_io_cleanup`, setting `info->fbdefio_state = NULL` is done without holding the state lock. This is fine for the fault/mkwrite paths (they go through the VMA's `vm_private_data`, not through `info`), but `fb_deferred_io_work` reads `info->fbdefio_state` without synchronization. This is safe only because `cancel_delayed_work_sync` prevents the work from running concurrently with this assignment — but see the race discussion above.

**Code quality is good.** The refcounting is straightforward, the SIGBUS return for dead devices is the right behavior, and the locking strategy is reasonable.

---

---
Generated by Claude Code Patch Reviewer