Claude review: accel/ivpu: Fix signed integer truncation in IPC receive

[Claude Code Review Bot <claude-review@example.com>]

Patch Review

**The bug is real and clearly explained.** Looking at the existing code:

```c
u32 size = min_t(int, rx_msg->ipc_hdr->data_size, sizeof(*jsm_msg));
```

`rx_msg->ipc_hdr->data_size` is `u32` (confirmed in `ivpu_ipc.h:38`), and `sizeof(*jsm_msg)` is `size_t`. The `min_t(int, ...)` cast truncates both to signed `int`. If firmware-supplied `data_size` is >= 0x80000000, the cast produces a negative value, which "wins" the min comparison, then gets assigned back to `u32 size` as a huge value, and the subsequent `memcpy(jsm_msg, rx_msg->jsm_msg, size)` at line 291 overflows.

**The fix is correct:**

```c
u32 size = min(rx_msg->ipc_hdr->data_size, sizeof(*jsm_msg));
```

- `data_size` is `u32`, `sizeof(...)` is `size_t` (unsigned). The kernel's `min()` macro handles type promotion correctly for unsigned types — `u32` will promote to `size_t` in the comparison, which is safe.
- The result is capped to `sizeof(*jsm_msg)` which fits in `u32`, so the assignment is also safe.

**Minor observations (not blocking):**

- The `sizeof(*jsm_msg)` operand has type `size_t`, while `data_size` has type `u32`. On 64-bit kernels these differ in width. The kernel's `min()` macro (using `__types_ok()`) permits this comparison when both are unsigned and one promotes safely. This works correctly, but if the build bot flags a type mismatch warning (some older kernel versions were stricter), `min_t(u32, ...)` would be the fallback. This should be fine on current kernels.

- The commit message and changelog are clean. The `Fixes:` tag references the correct commit that introduced `min_t(int, ...)`, and the `Cc: stable` annotation with `# v6.12+` is appropriate.

**Reviewed-by recommendation: This patch is correct and suitable for merging.**

---
Generated by Claude Code Patch Reviewer