Sashiko pointed out several issues in the iommufd invalidation path, which
also prompted a rework of the ARM SMMUv3 vIOMMU invalidation handler:

 - entry_len is user-controlled and unbounded, so the trailing-zero check
   for its forward-compat fields can scan gigabytes of user memory without
   yielding, long enough to trip the soft-lockup watchdog.

 - A large entry_num drives a backend's per-entry invalidation loop with no
   reschedule, e.g. the VT-d nested path, pinning the CPU.

 - The full-array copy helper copies the array twice on the equal-size fast
   path: once in bulk, then again entry by entry.

 - arm_vsmmu_cache_invalidate() reports converted-but-unsubmitted commands
   as handled on its error paths.

 - It sizes a single kernel allocation from the user-controlled entry_num.

 - It rejects an empty-array data_type probe that the uAPI allows.

Fix them properly.

This is on Github:
https://github.com/nicolinc/iommufd/commits/smmuv3_fix_iommufd-v1

Nicolin Chen (4):
  iommufd: Set upper bounds on cache invalidation entry_num and
    entry_len
  iommufd/selftest: Add invalidation entry_num and entry_len boundary
    tests
  iommu: Avoid copying the user array twice in the full-array copy
    helper
  iommu/arm-smmu-v3: Process vIOMMU invalidations in batches

 include/linux/iommu.h                         |  1 +
 .../arm/arm-smmu-v3/arm-smmu-v3-iommufd.c     | 91 +++++++++++--------
 drivers/iommu/iommufd/hw_pagetable.c          | 11 ++-
 tools/testing/selftests/iommu/iommufd.c       | 15 +++
 4 files changed, 81 insertions(+), 37 deletions(-)

-- 
2.43.0