From mboxrd@z Thu Jan  1 00:00:00 1970
From: Claude Code Review Bot <claude-review@example.com>
To: dri-devel-reviews@example.com
Subject: Claude review: drm/amd/ras: Fix type size of remainder argument
Date: Fri, 27 Feb 2026 14:18:28 +1000
Message-ID: <review-patch1-20260225014317.work.103-kees@kernel.org>
In-Reply-To: <20260225014317.work.103-kees@kernel.org>
References: <20260225014317.work.103-kees@kernel.org> <20260225014317.work.103-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 70-72 of `ras_core.c` decla=
res:
```c
int days, remaining_seconds;
...
days =3D div64_u64_rem(timestamp, seconds_per_day, (uint64_t *)&remaining_s=
econds);
```

`div64_u64_rem()` has the signature (from `include/linux/math64.h:54`):
```c
static inline u64 div64_u64_rem(u64 dividend, u64 divisor, u64 *remainder)
```

Writing a `u64` (8 bytes) through a pointer to a 4-byte `int` is an out-of-=
bounds stack write. On little-endian x86 this happens to work by luck (the =
low 4 bytes land correctly, and the high 4 bytes overflow into adjacent sta=
ck space), but it's undefined behavior and would produce wrong results on b=
ig-endian architectures.

**Fix review:** The patch changes `remaining_seconds` from `int` to `uint64=
_t` and removes the cast:
```c
+	uint64_t remaining_seconds;
...
+	days =3D div64_u64_rem(timestamp, seconds_per_day, &remaining_seconds);
```

This is the correct fix. The value stored in `remaining_seconds` (seconds w=
ithin a day, range 0=E2=80=9386399) fits comfortably in any integer type, s=
o the widening has no functional impact on the subsequent arithmetic at lin=
es 97-100 where `remaining_seconds` is used for division/modulo to compute =
hours, minutes, and seconds.

**Minor observations (not blocking):**

1. The return type of `div64_u64_rem()` is `u64`, but `days` remains `int`.=
 For timestamp values representable by a `u64`, the number of days could th=
eoretically exceed `INT_MAX` (~5.8 million years), but practically this is =
fine since the function processes realistic Unix timestamps. Not something =
this patch needs to address.

2. The `seconds_per_day`, `seconds_per_hour`, and `seconds_per_minute` vari=
ables are `int`, and they are passed as the `u64 divisor` argument to `div6=
4_u64_rem()` =E2=80=94 this is an implicit widening conversion which is saf=
e and correct. No issue here.

**Reviewed-by: Looks correct.** The fix is minimal, targeted, and solves bo=
th the `-Warray-bounds` warning and the underlying type-safety/endianness b=
ug.

---
Generated by Claude Code Patch Reviewer