From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: gpu: nova-core: fix stack overflow in GSP memory allocation Date: Sat, 14 Feb 2026 07:16:12 +1000 Message-ID: In-Reply-To: <20260213-drm-rust-next-v2-1-aa094f78721a@proton.me> References: <20260213-drm-rust-next-v2-1-aa094f78721a@proton.me> 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: gpu: nova-core: fix stack overflow in GSP memory allocation Author: Tim Kovalenko via B4 Relay Patches: 1 Reviewed: 2026-02-14T07:16:12.245002 --- This is a single-patch series (v2) fixing a stack overflow in the nova-core G= SP driver. The `PteArray` struct, when instantiated with a large number of en= tries, was being constructed on the stack before being copied into the DMA bu= ffer. For the command queue path (`Cmdq::new`), `GspMem` contains a `PteArray= <512>` (4096 bytes / 8 bytes per u64 =3D 512 entries), resulting in 4096 byte= s of stack-allocated PTEs. The patch eliminates the intermediate stack alloca= tion by computing and writing each PTE value directly into the DMA buffer one= at a time. The approach is sound and the two sites are handled differently due to their = different DMA abstractions: the `LogBuffer` path uses `as_slice_mut` to get a= mutable byte slice and writes PTEs via `copy_from_slice`, while the `Cmdq` p= ath uses raw pointer arithmetic with `addr_of_mut!` and `field_write` to writ= e individual array elements. Both approaches avoid the stack-allocated interm= ediate array. There is one correctness concern worth examining in the `Cmdq::new` path rela= ted to using `field_write` (which performs a volatile write) for individual a= rray elements versus the original `dma_write!` macro approach that wrote the = entire `PteArray` struct atomically. --- Generated by Claude Code Patch Reviewer