iommufd: Cache invalidation hardening and SMMUv3 batching rework

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