Claude review: Add DMA-buf mapping types and convert vfio/iommufd to use them

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

Overall Series Review

Subject: Add DMA-buf mapping types and convert vfio/iommufd to use them
Author: Jason Gunthorpe <jgg@nvidia.com>
Patches: 27
Reviewed: 2026-02-18T11:37:56.140993

---

This 26-patch RFC series from Jason Gunthorpe introduces a mapping type negotiation framework for DMA-buf, allowing importers and exporters to negotiate the data format used for map/unmap operations rather than being limited to scatterlist. The motivations are concrete: VFIO-to-iommufd needs physical addresses rather than dma_addr_t, xe vGPU needs internal VRAM addresses, and there's ongoing work to replace scatterlist more broadly.

The architecture is well-designed. A match-making system during attach lets each side declare what it supports, with exporter priority controlling selection. The SGT type wraps existing behavior transparently, and a new PAL (Physical Address List) type demonstrates extensibility. The series follows a disciplined progression: introduce framework, add compatibility wrappers so everything works unchanged, convert drivers incrementally, clean up legacy interfaces, then add the new PAL type. The `EXPORT_SYMBOL_FOR_MODULES` restriction on PAL importers to prevent physical address misuse is a thoughtful security measure.

The main issues found are: a latent NULL dereference in the new `dma_buf_dynamic_attach` wrapper (patch 3), a dual-purpose enum that conflates exporter and importer p2p semantics (patch 2), and the `dma_buf_get_sgt_ops()` call ordering relative to NULL checks (patch 4). There is also an asymmetry in symbol export for PAL map vs unmap that deserves a brief explanation. None of these are blockers for an RFC, but the NULL deref in patch 3 should be addressed before the next revision.

---
Generated by Claude Code Patch Reviewer