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/[email protected]/
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/[email protected]/
Jason noted that this showed the same private-IOMMU-domain mapping need as
IOMMUFD:
https://lore.kernel.org/r/[email protected]/
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/[email protected]/
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/[email protected]/
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/[email protected]/
https://lore.kernel.org/r/[email protected]/
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)
