Re: [PATCH] Fixes a race in iopt_unmap_iova_range

[Jason Gunthorpe]

On Mon, Apr 06, 2026 at 03:00:36PM -0700, Sina Hassani wrote:
> Bug: iopt_unmap_iova_range releases the lock on iova_rwsem inside the loop
> body when getting to the more expensive unmap operations. This is fine on
> its own except the loop condition is based on the first area that matches
> the unmap address range. If a concurrent call to map picks an area that was
> unmapped in the previous iterations, this loop will try to mistakenly unmap
> them.

Does this mean you are also using the automatic IOVA allocator?

It is certainly an error for userspace to be mapping to IOVA that is
under concurrent unmap.

> io_pagetable *iopt, unsigned long start,
>                 iopt_put_pages(pages);
> 
>                 unmapped_bytes += area_last - area_first + 1;
> +               start = area_last + 1;

This seems like a reasonable solution, but area_last + 1 can overflow
and that needs to be delt with too.

/* Do not reconsider things already unmapped in case of concurrent allocation */
if (area_last != last)
   start = area_last + 1;

?

Jason