Claude review: dma-buf: Fix silent overflow for phys vec to sgt

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

Patch Review

**The core bug fix (mapped_len) — correct:**

```c
-	unsigned int nents, mapped_len = 0;
 	struct dma_buf_dma *dma;
 	struct scatterlist *sgl;
+	size_t mapped_len = 0;
+	unsigned int nents;
```

This is the primary fix. `mapped_len` accumulates `phys_vec[i].len` which is `size_t` (confirmed from `struct phys_vec` in `include/linux/types.h:173`). With a >4GB MMIO region, the old `unsigned int` silently wraps. The downstream consumers `dma_iova_sync()` and `fill_sg_entry()` both take `size_t` length parameters, so `size_t mapped_len` is the correct type. The variable reordering follows reverse Christmas tree style — good.

**The calc_sg_nents overflow protection — correct:**

```c
-	unsigned int nents = 0;
+	size_t nents = 0;
```

Using `size_t` for the intermediate accumulation is correct. In the non-IOVA path, the loop `nents += DIV_ROUND_UP(phys_vec[i].len, UINT_MAX)` accumulates across `nr_ranges` entries, and theoretically could exceed `UINT_MAX` with enough large ranges. The function still returns `unsigned int`, which matches what `sg_alloc_table()` expects (`unsigned int nents` per `include/linux/scatterlist.h:464`).

```c
+	if (nents > UINT_MAX)
+		return 0;
```

Returning 0 as a sentinel for overflow is a reasonable convention given that 0 nents is never a valid return from this function (it would mean zero-length mapping, which callers shouldn't request).

**The caller-side overflow check — correct:**

```c
 	nents = calc_sg_nents(dma->state, phys_vec, nr_ranges, size);
+	if (!nents) {
+		ret = -EINVAL;
+		goto err_free_state;
+	}
```

The goto target `err_free_state` is correct for this point in the function — `dma->state` may have been allocated by the `PCI_P2PDMA_MAP_THRU_HOST_BRIDGE` path above, and `dma` itself also needs freeing. Both are handled by the `err_free_state` → `err_free_dma` cleanup chain.

**Minor note:** This conflates "overflow" with "legitimately zero nents" under a single `-EINVAL`. In practice, zero nents would only happen if the caller passes `size=0` or `nr_ranges=0`, both of which are caller bugs deserving `-EINVAL` anyway, so no issue.

**The fill_sg_entry type consistency fix — fine:**

```c
-	int i;
+	unsigned int i;
```

This matches `i` to the type of `nents` (`unsigned int`), eliminating a signed/unsigned comparison in `i < nents`. Not a practical bug (nents here is computed from a single range's length, so always small), but it's the right type and silences compiler warnings.

**Commit message:** Clear and accurate. The Fixes tag references the correct introducing commit. The Cc: stable is appropriate for a data corruption bug. The changelog across v2-v5 shows responsive iteration to reviewer feedback.

**No issues found. Reviewed-by quality.**

---
Generated by Claude Code Patch Reviewer