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/amd/ras: Fix type size of remainder argument Date: Fri, 27 Feb 2026 13:07:15 +1000 Message-ID: In-Reply-To: <20260225174702.it.918-kees@kernel.org> References: <20260225174702.it.918-kees@kernel.org> <20260225174702.it.918-kees@kernel.org> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Patch Review **Problem analysis:** The original code at line 72: ```c int days, remaining_seconds; days =3D div64_u64_rem(timestamp, seconds_per_day, (uint64_t *)&remaining_s= econds); ``` `div64_u64_rem()` takes a `u64 *remainder` parameter (confirmed in `include= /linux/math64.h:54`) and writes 8 bytes through it. But `remaining_seconds`= is `int` (4 bytes). The cast `(uint64_t *)&remaining_seconds` silences the= compiler but creates two real bugs: 1. **Stack corruption**: 4 bytes of adjacent stack are overwritten. 2. **Endianness bug**: On big-endian systems, the meaningful lower 32 bits = of the remainder end up in the wrong half. **Fix analysis:** The patch introduces a properly-typed `u64 remainder` tem= porary: ```c uint64_t month =3D 0, day =3D 0, hour =3D 0, minute =3D 0, second =3D 0, re= mainder; ... days =3D div64_u64_rem(timestamp, seconds_per_day, &remainder); /* remainder will always be less than seconds_per_day. */ remaining_seconds =3D remainder; ``` This is the right approach for v2. The v1 presumably changed `remaining_sec= onds` itself to `u64`, which would then require `do_div()` or similar at th= e later division sites (lines 98-100). By using a temporary and assigning b= ack to `int`, the subsequent arithmetic on `remaining_seconds` stays as nat= ive `int` division =E2=80=94 no 64-bit division helpers needed. **Comment on the comment:** The inline comment `/* remainder will always be= less than seconds_per_day. */` is helpful =E2=80=94 it justifies the narro= wing assignment. `seconds_per_day` is 86400, well within `int` range, so th= e truncation is safe. **One minor observation:** `days` is also `int` (32-bit) and receives the r= eturn value of `div64_u64_rem()`, which returns `u64`. For a Unix timestamp= , this quotient is the number of days since epoch =E2=80=94 currently ~20,5= 00 and growing. An `int` can hold up to ~2.1 billion days, so this is safe = in practice, but it's a preexisting issue and outside the scope of this pat= ch. **Verdict:** The fix is correct, well-motivated, and minimal. The Fixes tag= correctly references the commit that introduced the buggy code. No issues = found. Reviewed-by quality: **Good to merge as-is.** --- Generated by Claude Code Patch Reviewer