Re: [PATCH] Fixes a race in iopt_unmap_iova_range

[Sina Hassani]

On Mon, Apr 6, 2026 at 3:17 PM Jason Gunthorpe <jgg@xxxxxxxx> wrote:
>
> 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.
>
Correct.

> > 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.
>
Good point, done. I sent you a v2 patch.

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

> Jason