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: fbdev: defio: Keep module reference from VMAs
Date: Fri, 27 Feb 2026 15:29:26 +1000
Message-ID: <review-patch2-20260224082657.207284-3-tzimmermann@suse.de>
In-Reply-To: <20260224082657.207284-3-tzimmermann@suse.de>
References: <20260224082657.207284-1-tzimmermann@suse.de> <20260224082657.207284-3-tzimmermann@suse.de>
X-Mailer: Claude Code Patch Reviewer
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Patch Review

Short and correct. Prevents the fbdev core module from being unloaded while=
 userspace VMAs exist.

```c
static void fb_deferred_io_vm_open(struct vm_area_struct *vma)
{
	struct fb_deferred_io_state *fbdefio_state =3D vma->vm_private_data;

	WARN_ON_ONCE(!try_module_get(THIS_MODULE));
	fb_deferred_io_state_get(fbdefio_state);
}
```

The `WARN_ON_ONCE` around `try_module_get` in `vm_open` is appropriate =E2=
=80=94 `vm_open` is called during VMA duplication (e.g., fork) and cannot f=
ail, so warning is the best we can do if the module is somehow being unload=
ed concurrently.

```c
static void fb_deferred_io_vm_close(struct vm_area_struct *vma)
{
	struct fb_deferred_io_state *fbdefio_state =3D vma->vm_private_data;

	fb_deferred_io_state_put(fbdefio_state);
	module_put(THIS_MODULE);
}
```

The ordering in `vm_close` is correct: release the state reference (which m=
ay call into module code via `fb_deferred_io_state_release`) *before* dropp=
ing the module reference.

In `fb_deferred_io_mmap`:

```c
if (!try_module_get(THIS_MODULE))
	return -EINVAL;
```

This correctly guards the initial mmap. No issues with this patch.

---

---
Generated by Claude Code Patch Reviewer