From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: rust: sync: Introduce LazyInit Date: Thu, 04 Jun 2026 16:11:03 +1000 Message-ID: In-Reply-To: <20260529173137.303717-1-lyude@redhat.com> References: <20260529173137.303717-1-lyude@redhat.com> 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: rust: sync: Introduce LazyInit Author: Lyude Paul Patches: 6 Reviewed: 2026-06-04T16:11:03.339061 --- This is a well-structured 2-patch series from Lyude Paul introducing `LazyI= nit`, a thread-safe lazy-initialization container for the kernel's Rust = abstractions. The motivation is clear: the existing `SetOnce` cannot handle= fallible initializers and doesn't allow racing callers to block until init= ialization completes. `LazyInit` solves both by using a `Mutex` for synchro= nization. **Patch 1** adds a small utility method `Lock::get_mut_pinned()` that Patch= 2 depends on. **Patch 2** is the bulk of the work =E2=80=94 a new `LazyIni= t` type with Mutex-based synchronization, fallible `PinInit` support, `r= eset()` capability, and thorough kunit tests. The design is sound: the Mutex protects only initialization, while post-ini= t access is lock-free (relying on `T: Send + Sync`). The lifetime extension= pattern via `mem::transmute` in `data()` is the riskiest construct but is = correctly justified. The `reset()` implementation using `ptr::drop_in_place= ` on `Inner` is subtle but correct given that `PinnedDrop` leaves `Inner` i= n a well-defined uninitialized state and the fields have no drop glue of th= eir own. There are a few documentation bugs and minor issues detailed below, but no = correctness issues found. --- --- Generated by Claude Code Patch Reviewer