From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: Fix missing fops.owner in Rust DRM/misc abstractions Date: Mon, 25 May 2026 20:45:42 +1000 Message-ID: In-Reply-To: <20260521-fix-fops-owner-v2-0-fd99079c5a04@linux.dev> References: <20260521-fix-fops-owner-v2-0-fd99079c5a04@linux.dev> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Overall Series Review Subject: Fix missing fops.owner in Rust DRM/misc abstractions Author: Alvin Sun Patches: 8 Reviewed: 2026-05-25T20:45:42.806892 --- This is a well-motivated fix for a real use-after-free bug in Rust DRM/misc= device drivers. When `fops.owner` is NULL, the kernel cannot take a module = reference when a file descriptor is opened, allowing `rmmod` to proceed whi= le userspace still holds an open fd =E2=80=94 leading to the NULL pointer d= ereference shown in the cover letter's backtrace. The design is clean: move `THIS_MODULE` into the existing `ModuleMetadata` = trait, have the `#[vtable]` macro auto-inject a `ThisModule` associated typ= e (trait side) and auto-set it to `crate::LocalModule` (impl side), then th= read that through to `fops.owner` in DRM and miscdevice. Patches 6-7 are st= raightforward usage-site updates for configfs and rnull. The series is logically ordered: infrastructure first (patches 1-3), then t= he actual bug fixes (patches 4-5), then mechanical updates (patches 6-7). T= he approach of encoding the module identity as a type-level associated type= is a reasonable Rust-idiomatic choice that avoids runtime parameters. **Overall assessment: Good series that fixes a real security/stability bug.= A few minor observations below, but nothing blocking.** --- Generated by Claude Code Patch Reviewer