Claude review: accel/ivpu: Add buffer overflow check in MS get_info_ioctl

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

Patch Review

**Purpose and correctness:**

The call chain is:
1. `ivpu_jsm_metric_streamer_info()` is called with `ivpu_bo_size(bo)` as the buffer size limit (line 290), and fills `info_size` (a `u64`) with the actual data size returned by firmware.
2. `info_size` is then used directly at line 299 in `copy_to_user(..., info_size)`.

If firmware returns an `info_size` larger than `ivpu_bo_size(bo)`, the `copy_to_user` would read past the end of the BO's mapped memory. The new check correctly catches this case before the data is used.

The placement is correct — right after the JSM call succeeds (line 291-292) and before either the `args->buffer_size` comparison or the `copy_to_user`. This ensures the firmware-returned size is validated against the kernel buffer before any further use.

**Format string nit:**

```c
ivpu_warn_ratelimited(vdev, "MS info overflow: %#llx > %#zx\n",
                      info_size, ivpu_bo_size(bo));
```

`info_size` is `u64` — in the kernel, the canonical format specifier for `u64` is `%llu` (or `%#llx` for hex, which is used here). That's fine. `ivpu_bo_size()` returns `size_t`, and `%zx` is appropriate for that. So the format specifiers are correct.

However, one could argue that a decimal format would be more readable for sizes in a warning message (comparing `0x10001` vs `0x10000` is harder to eyeball than `65537 > 65536`). This is purely a style preference and not a bug.

**Error code:**

`-EOVERFLOW` is a reasonable choice for this condition — it clearly conveys that the returned data would overflow the allocated buffer. Some drivers use `-ENOSPC` for related conditions, but `EOVERFLOW` better captures the "firmware returned more than it should have" semantics, distinguishing it from the existing `-ENOSPC` check on the user buffer (line 294).

**No concerns with the fix itself.** The patch is correct, minimal, and addresses a real vulnerability where firmware could cause an out-of-bounds kernel memory read that gets copied to userspace.

Reviewed-by assessment: **Acceptable as-is.**

---
Generated by Claude Code Patch Reviewer