Re: [PATCH v5 3/4] iommu: debug-pagealloc: Track IOMMU pages

[Mostafa Saleh]

On Fri, Jan 9, 2026 at 7:34 AM Pranjal Shrivastava <praan@xxxxxxxxxx> wrote:
>
> On Fri, Jan 09, 2026 at 11:28:32AM +0800, Baolu Lu wrote:
> > On 1/8/26 19:33, Mostafa Saleh wrote:
> > > I have this, it should have the same effect + a WARN, I will include
> > > it in the new version
> > >
> > > diff --git a/drivers/iommu/iommu-debug-pagealloc.c
> > > b/drivers/iommu/iommu-debug-pagealloc.c
> > > index 5353417e64f9..64ec0795fe4c 100644
> > > --- a/drivers/iommu/iommu-debug-pagealloc.c
> > > +++ b/drivers/iommu/iommu-debug-pagealloc.c
> > > @@ -146,16 +146,12 @@ void __iommu_debug_unmap_end(struct iommu_domain *domain,
> > >          if (unmapped == size)
> > >                  return;
> > >
> > > -       /*
> > > -        * If unmap failed, re-increment the refcount, but if it unmapped
> > > -        * larger size, decrement the extra part.
> > > -        */
> > > +       /* If unmap failed, re-increment the refcount. */
> > >          if (unmapped < size)
> > >                  __iommu_debug_update_iova(domain, iova + unmapped,
> > >                                            size - unmapped, true);
> > >          else
> > > -               __iommu_debug_update_iova(domain, iova + size,
> > > -                                         unmapped - size, false);
> > > +               WARN_ONCE(1, "iommu: unmap larger than requested is
> > > not supported in debug_pagealloc\n");
> > >   }
> > >
> > >   void iommu_debug_init(void)
> >
> > How aobut
> >
> >       if ((unmapped == size) || WARN_ON_ONCE(unmapped > size))
> >               return;
> >
> >       /* If unmap failed, re-increment the refcount. */
> >       __iommu_debug_update_iova(domain, iova + unmapped, size - unmapped, true);
> >
> > ?
> >
>
> That's nice, We could also print the message as Mostafa mentioned, like:
>
>         if ((unmapped == size) || WARN_ON_ONCE(unmapped > size,
>         "iommu: unmap larger than requested is not supported in
>         debug_pagealloc\n"))
>
> An explicit "This is unsupported" warning makes it clear IMHO.
> If a driver triggers this, at least we know the sanitizer state isn't
> supported.
>

I guess both are fine, the WARN points to the line which should be
simple to deduce the cause anyway.

Thanks,
Mostafa

> Thanks,
> Praan