From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: drm/i915: Fix potential overflow of shmem scatterlist length Date: Fri, 27 Feb 2026 15:21:32 +1000 Message-ID: In-Reply-To: <20260224094944.2447913-2-janusz.krzysztofik@linux.intel.com> References: <20260224094944.2447913-2-janusz.krzysztofik@linux.intel.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Overall Series Review Subject: drm/i915: Fix potential overflow of shmem scatterlist length Author: Janusz Krzysztofik Patches: 7 Reviewed: 2026-02-27T15:21:32.541027 --- This is a single-patch fix for a real overflow bug in the i915 shmem scatterlist allocation path. The `sg->length` field is `unsigned int` (32-bit), and when contiguous folios are coalesced into a single scatterlist entry, the accumulated length can overflow past 4GB. The bug was acknowledged by the original author with a `/* XXX: could overflow? */` comment but never fixed. The fix is targeted at the right code and the commit message, Fixes tag, stack trace, and Cc: stable are all correct. However, the patch introduces a **new correctness issue**: when a folio must be split across two sg entries (because it straddles the `max_segment` boundary), the code re-fetches the same folio in the next loop iteration but maps it from offset 0, double-mapping the pages at the start of the folio while losing the pages at the tail. There is also a minor style concern with the use of `min_array` and a compound literal where `min3` would be more conventional. **Verdict**: The fix addresses a real, triggerable bug but needs a respin to correctly handle partial-folio splits. --- --- Generated by Claude Code Patch Reviewer