Re: [PATCH v1 0/4] iommufd: Cache invalidation hardening and SMMUv3 batching rework

[Jason Gunthorpe <jgg@nvidia.com>]

On Wed, Jun 03, 2026 at 02:26:52PM -0700, Nicolin Chen wrote:
> 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

I picked up these ones, lets resend this next cycle for Will:

>   iommu/arm-smmu-v3: Process vIOMMU invalidations in batches

Thanks,
Jason