From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: vfs: change kino_t from unsigned long to u64 Date: Wed, 04 Mar 2026 08:15:04 +1000 Message-ID: In-Reply-To: <20260302-iino-u64-v2-60-e5388800dae0@kernel.org> References: <20260302-iino-u64-v2-0-e5388800dae0@kernel.org> <20260302-iino-u64-v2-60-e5388800dae0@kernel.org> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Patch Review This is the keystone patch -- the actual type widening. It's a 2-line change: ```c -typedef unsigned long kino_t; -#define PRIino "l" +typedef u64 kino_t; +#define PRIino "ll" ``` Because all format strings already use `PRIino` and all relevant local variables/parameters use `kino_t` or `u64`, this compiles cleanly. The commit message is thorough, mentioning the existing overflow checks in `cp_new_stat()`, `cp_old_stat()`, and `cp_compat_stat()` that handle narrowing to 32-bit `st_ino` with `-EOVERFLOW`. **One question**: Does `struct inode` alignment need attention on 32-bit after this change? The `i_ino` field is preceded by `void *i_security` (under `CONFIG_SECURITY`) or padding fields, and followed by the `nlink` union. On 32-bit with 8-byte aligned u64, this could introduce a 4-byte hole before `i_ino`. The commit message mentions "struct inode will grow by at least 4 bytes" but doesn't address whether the field ordering was reviewed for optimal packing. This would be worth investigating, though it's a minor optimization concern rather than a correctness issue. ### PATCHES 61-109: Replace PRIino with %llu/%llx These are the reverse of patches 8-58, replacing the temporary `PRIino` macro with the final concrete format specifiers. Mechanical and correct. The `kino_t` casts become `u64` casts. --- Generated by Claude Code Patch Reviewer