From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: iommu/io-pgtable: introduce iova_to_phys_length in io_pgtable_ops Date: Thu, 04 Jun 2026 15:00:34 +1000 Message-ID: In-Reply-To: <20260531093637.3893199-3-guanghuifeng@linux.alibaba.com> References: <20260531093637.3893199-1-guanghuifeng@linux.alibaba.com> <20260531093637.3893199-3-guanghuifeng@linux.alibaba.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Patch Review Clean mechanical changes to ARM LPAE, ARM v7s, and DART backends. **v7s concern** -- the `blk_size` calculation: ```c blk_size = ~mask + 1U; ``` When `mask` has been multiplied by `ARM_V7S_CONT_PAGES` (16), this gives the contiguous block size. The `1U` suffix means unsigned 32-bit arithmetic. Since `mask` is `u32`, this is fine, but on a 32-bit ARM with a 4GB mask this could theoretically overflow. In practice the masks used here are well below that, so this is OK. **Selftest changes in v7s**: The selftests switch from `ops->iova_to_phys()` to `ops->iova_to_phys_length(ops, ..., NULL)` but none of them actually test the new `mapped_length` output. This is a missed opportunity -- it would be very valuable to add selftest coverage verifying that the returned `mapped_length` matches the expected page size for each mapping. **DART backend**: Using `data->iop.cfg.pgsize_bitmap` as `mapped_length` is questionable: ```c pgsize = data->iop.cfg.pgsize_bitmap; if (mapped_length) *mapped_length = pgsize; ``` `pgsize_bitmap` is a bitmask of *supported* page sizes, not the actual page size of the mapping. For DART (Apple), the bitmap happens to be a single bit (one fixed page size), so treating it as a size works by accident. This should at minimum have a comment explaining why it's correct, or better, use `__ffs(pgsize_bitmap)` / `BIT()` to be explicit. The v2 cover letter doesn't mention fixing this. --- Generated by Claude Code Patch Reviewer