[RFC PATCH 0/6] iommufd: harden DMA-BUF PAL setup and release

[Karl Mehltretter <kmehltretter@gmail.com>]

This is a narrow companion to Jason's unmerged DMA-BUF mapping-type RFC. It
fixes setup and release problems in the IOMMUFD PAL consumer and adds fault-
injection selftests. It is not standalone and requires this exact base:

  c37cf2824740d ("cover-letter: Add DMA-buf mapping types and convert
                  vfio/iommufd to use them")

I used LLM assistance while inspecting, testing and drafting this series.

I also tested DMA-BUF paths on a Raspberry Pi 400 and Pi 500+, using their
stock Raspberry Pi kernels (6.18.39+rpt-rpi-v8 and 6.18.34+rpt-rpi-2712).
Both passed offscreen CPU/V3D byte checks. The Pi 400 also passed five raw-MJPG
payload-prefix comparisons through V3D; this was not direct or zero-copy camera
DMA. Neither board ran this RFC or IOMMUFD PAL. The Pi 500+ connector state and
mode remained unchanged; the tested buffers were not scanned out.

RFC:
https://lore.kernel.org/r/0-v1-b5cab63049c0+191af-dmabuf_map_type_jgg@nvidia.com/

Jason's branch:
https://github.com/jgunthorpe/linux/commits/dmabuf_map_type

This series:
https://github.com/kmehltretter82/linux/commits/dmabuf-pal-lifecycle-rfc-v1

Diederik's RK3588 testing produced a useful trace through
rockchip_gem_iommu_map() and iommu_map_sg():

https://lore.kernel.org/r/DLYLA3WQNN3X.3FB9MO8ZWBQ5@cknow-tech.com/

Jason noted that this showed the same private-IOMMU-domain mapping need as
IOMMUFD:

https://lore.kernel.org/r/20261009125338.GB13920@nvidia.com/

That trace is motivation only. This series neither revives my warn-only
mechanism nor converts Rockchip. Jason's feedback on that mechanism is here:

https://lore.kernel.org/r/20261009124259.GA13920@nvidia.com/

Compared with Jason's branch, this series:

  - preserves dma_buf_pin() errors;
  - publishes the attachment and successful PAL list together under resv;
  - unmaps and clears the published PAL pointer under resv before unlocking;
  - keeps callback state alive until dma_buf_detach() returns;
  - calls dma_buf_unpin() while holding resv; and
  - tests pin/map failures, cleanup counters and retry on the same DMA-BUF.

Patch 3 follows an earlier forced-window arm64 QEMU/KASAN double-free report:

https://lore.kernel.org/r/20261016194022.62065-1-kmehltretter@gmail.com/

The proposed release order is:

  resv lock -> unmap and clear PAL -> unpin -> unlock -> detach -> put ->
  destroy the pages mutex

Questions:

1. Is that publication and lifetime rule correct?

2. Is c37cf2824740d still the right base for this companion series? If not,
   which tree should I use?

3. Can these lifecycle fixes stand independently of moving final mapping
   selection closer to map time?

   https://lore.kernel.org/r/20261016202653.97339-1-kmehltretter@gmail.com/
   https://lore.kernel.org/r/20261019184123.GR13920@nvidia.com/

4. Is the per-buffer selftest control acceptable, or would deterministic
   setup/release race hooks be more useful?

Testing:

  - arm64 QEMU virt: two boots, 24 selected cases per boot, zero skips;
  - x86-64 KVM q35: two 24-case candidate boots plus one focused four-case
    pin-failure boot;
  - a one-defect x86 control failed all four pin-failure variants on the
    expected erroneous successful ioctl return;
  - x86-64 GCC 13.3 built the exact head, headers and IOMMUFD selftests; this
    build was not booted; and
  - KASAN and lockdep initialized with no diagnostics in candidate runs.

The QEMU/KVM campaigns use mock IOMMU domains and the selftest exporter. They
do not cover a non-selftest PAL exporter, physical DMA/IOMMU, forced
invalidation races, or the complete IOMMUFD selftest suite. The x86 negative
control validates patch 1 only; the earlier patch-3 report is separate.

Testing with a non-selftest PAL exporter would be welcome, especially failure
followed by retry, invalidation during setup/release, repeated revoke, and
multi-range buffers. Please include the base, config, architecture,
exporter/device and full dmesg. A full IOMMUFD selftest run on another
configuration would also help.

Thanks,
Karl

Karl Mehltretter (6):
  iommufd: Preserve DMA-buf pin errors
  iommufd: Publish successful PAL mappings under resv
  iommufd: Clear the PAL list before dropping resv
  iommufd: Keep the pages mutex alive until DMA-buf detach
  iommufd: Unpin the DMA-buf while holding resv
  iommufd/selftest: Check DMA-buf pin and map failure cleanup

 drivers/iommu/iommufd/iommufd_test.h          |  24 ++++
 drivers/iommu/iommufd/pages.c                 |  24 ++--
 drivers/iommu/iommufd/selftest.c              | 111 ++++++++++++++++
 tools/testing/selftests/iommu/iommufd.c       | 121 ++++++++++++++++++
 tools/testing/selftests/iommu/iommufd_utils.h |  30 +++++
 5 files changed, 298 insertions(+), 12 deletions(-)


base-commit: c37cf2824740d833b21eb816e21f94836100291f
-- 
2.39.5 (Apple Git-154)