Claude review: iov_iter: add iterator type for dmabuf maps

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

Patch Review

Introduces `ITER_DMABUF_MAP` iterator type. The approach of treating it as an opaque handle that only the target driver can interpret is sound.

**Issue: Pre-existing parenthesization bug perpetuated in `iov_iter_restore`**

The patch modifies the `WARN_ON_ONCE` in `iov_iter_restore` but does not fix the existing mis-parenthesization:

```c
if (WARN_ON_ONCE(!iov_iter_is_bvec(i) && !iter_is_iovec(i) &&
		 !iter_is_ubuf(i) && !iov_iter_is_kvec(i) &&
		 !iov_iter_is_dmabuf_map(i)))
```

The original code has:
```c
if (WARN_ON_ONCE(!iov_iter_is_bvec(i) && !iter_is_iovec(i) &&
		 !iter_is_ubuf(i)) && !iov_iter_is_kvec(i))
```

The closing paren of `WARN_ON_ONCE` comes after `!iter_is_ubuf(i)`, meaning `!iov_iter_is_kvec(i)` is checked *after* the WARN fires, not as part of the condition. The patched version fixes this by moving the closing paren to include all the checks, but this is done silently — it should be called out since it changes the existing behavior (kvec iterators would previously pass through without warning, now they'd warn if somehow removed from the list). This is actually a bugfix that should be noted in the commit message or split out.

**Minor: `iov_iter_alignment` shares ubuf path**

```c
if (likely(iter_is_ubuf(i)) || iov_iter_is_dmabuf_map(i)) {
    ...
    return ((unsigned long)i->ubuf + i->iov_offset) | size;
```

This accesses `i->ubuf` for a dmabuf_map iterator. Since `ubuf` and `dmabuf_map` are in a union, this is reading the `dmabuf_map` pointer as a `void __user *`, which works for alignment checking purposes but is semantically odd. The comment or code should clarify that alignment of dmabuf_map iterators is always satisfied, or this path should return 0 for dmabuf_map iterators explicitly.

---

---
Generated by Claude Code Patch Reviewer