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

[Alistair Popple <apopple@nvidia.com>]

On 2026-10-20 at 17:37 +1100, Karl Mehltretter <kmehltretter@gmail.com> wrote...
> 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?

The discussion upstream on whether the PAL approach is acceptable still hasn't
settled AFAICT. I'm starting to look at alternate approaches but don't have
anything concrete yet. However as part of that work I have rebased Jason's
branch onto a more recent upstream (v7.3-rc5) so if you wanted to rebase this
work onto that it could be useful.

I haven't had a chance to look at these patches yet, but if some of them are
fixing bugs in Jason's series it might be best for us to fold them into that
series, with correct attribution of course. Anyway I will take a closer look in
the morning.

Thanks.

 - Alistair

> 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)
>