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

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

Patch Review

**Commit message nit:** There's a dangling fragment in the commit message body:

```
to mapped_len, and leading to a silent overflow
```

This line (line 103 of the mbox) looks like leftover text from an earlier draft that wasn't cleaned up. It should be removed before merging.

**`mapped_len` promotion (main fix) — correct:**

```c
-	unsigned int nents, mapped_len = 0;
...
+	size_t mapped_len = 0;
+	unsigned int nents;
```

This is the core fix. `mapped_len` accumulates `phys_vec[i].len` values (which are `size_t`) at line 154 of the source:

```c
mapped_len += phys_vec[i].len;
```

With >4GB total MMIO, the old `unsigned int` wraps silently. Then `dma_iova_sync()` and `fill_sg_entry()` receive a truncated length, which is a data-corruption-grade bug. The fix is correct and minimal.

**`fill_sg_entry` loop iterator — correct but cosmetic:**

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

The loop compares `i < nents` where `nents` is `unsigned int`. Using a signed `int` for the iterator means the comparison is well-defined (the signed value gets implicitly converted), so this is not a functional bug, but matching signedness is cleaner and avoids compiler warnings with `-Wsign-compare`. Fine to include.

**`calc_sg_nents` overflow guard — needs attention:**

```c
-	unsigned int nents = 0;
+	size_t nents = 0;
...
+	if (nents > UINT_MAX)
+		return 0;
```

The function signature still returns `unsigned int`:

```c
static unsigned int calc_sg_nents(struct dma_iova_state *state, ...)
```

Promoting `nents` to `size_t` locally and clamping to `UINT_MAX` before returning is logically correct — it prevents the intermediate accumulation from overflowing before the check. However, there are concerns:

1. **Returning 0 on overflow is a silent failure.** The caller at line 135-137 does:

   ```c
   nents = calc_sg_nents(dma->state, phys_vec, nr_ranges, size);
   ret = sg_alloc_table(&dma->sgt, nents, GFP_KERNEL | __GFP_ZERO);
   ```

   Passing `nents = 0` to `sg_alloc_table()` — which takes `unsigned int nents` — will cause `sg_alloc_table` to fail (it returns `-EINVAL` for 0 entries per the kernel implementation). So the error *will* propagate, but through `sg_alloc_table` failing rather than `calc_sg_nents` explicitly signaling the problem. This works but is fragile — it relies on `sg_alloc_table`'s behavior for a degenerate input rather than the caller explicitly handling the overflow. A `WARN_ON_ONCE` or explicit error return (e.g., returning `UINT_MAX` with a warning, or having the caller check for 0) would make the failure mode more obvious and debuggable.

2. **The non-IOVA path can also overflow.** In the loop:

   ```c
   for (i = 0; i < nr_ranges; i++)
       nents += DIV_ROUND_UP(phys_vec[i].len, UINT_MAX);
   ```

   Each `phys_vec[i].len` produces at least 1 entry, and `nr_ranges` is `size_t`. If `nr_ranges` is extremely large (though unlikely in practice for MMIO regions), `nents` could still overflow even as `size_t` on 64-bit. The `> UINT_MAX` check after the loop catches this, so it's fine. But the IOVA path with `DIV_ROUND_UP(size, UINT_MAX)` will never exceed `UINT_MAX` on 64-bit since `size` is `size_t` (at most 2^64-1 / (2^32-1) ≈ 2^32), so the check is mostly relevant for the non-IOVA accumulation path.

**Reverse Christmas tree ordering — correct:**

The variable declarations in `dma_buf_phys_vec_to_sgt` are properly reordered by line length:

```c
	struct dma_buf_dma *dma;
	struct scatterlist *sgl;
	size_t mapped_len = 0;
	unsigned int nents;
	dma_addr_t addr;
	size_t i;
	int ret;
```

This follows the kernel coding style convention.

**Summary:** The core `mapped_len` overflow fix is correct and important. The `calc_sg_nents` overflow guard works but returning 0 silently is not ideal — consider adding a `WARN_ON_ONCE(nents > UINT_MAX)` before the return so the failure is visible in dmesg rather than silently propagating through `sg_alloc_table`. The dangling text fragment in the commit message ("to mapped_len, and leading to a silent overflow") must be removed.

---
Generated by Claude Code Patch Reviewer