Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1374224

Re: [PATCH v2 1/2] dma/iommu: Add pgsize_bitmap confirmation in __iommu_dma_alloc_pages

From Will Deacon <will.deacon@arm.com>
Newsgroups linux.kernel
Subject Re: [PATCH v2 1/2] dma/iommu: Add pgsize_bitmap confirmation in __iommu_dma_alloc_pages
Date 2016-04-08 15:10 +0200
Message-ID <rlEkG-4cu-9@gated-at.bofh.it> (permalink)
References <rhz0d-36r-1@gated-at.bofh.it> <ri5js-TR-11@gated-at.bofh.it> <rkCEj-7qs-9@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Tue, Apr 05, 2016 at 10:03:32AM -0700, Doug Anderson wrote:
> On Tue, Mar 29, 2016 at 10:02 AM, Will Deacon <will.deacon@arm.com> wrote:
> > On Mon, Mar 28, 2016 at 02:32:11PM +0800, Yong Wu wrote:
> >> @@ -213,13 +215,16 @@ static struct page **__iommu_dma_alloc_pages(unsigned int count, gfp_t gfp)
> >>               /*
> >>                * Higher-order allocations are a convenience rather
> >>                * than a necessity, hence using __GFP_NORETRY until
> >> -              * falling back to single-page allocations.
> >> +              * falling back to min size allocations.
> >>                */
> >> -             for (order = min_t(unsigned int, order, __fls(count));
> >> -                  order > 0; order--) {
> >> -                     page = alloc_pages(gfp | __GFP_NORETRY, order);
> >> +             for (order = min_t(int, order, __fls(count));
> >> +                  order >= min_order; order--) {
> >> +                     page = alloc_pages((order == min_order) ? gfp :
> >> +                                        gfp | __GFP_NORETRY, order);
> >>                       if (!page)
> >>                               continue;
> >> +                     if (!order)
> >> +                             break;
> >
> > Isn't this handled by the loop condition?
> 
> He changed the loop condition to be ">= min_order" instead of "> 0",
> so now we can get here with an order == 0.  This makes sense because
> when min_order is not 0 you still want to run the code to split the
> pages and it is sane not to duplicate that below.
> 
> Maybe I'm misunderstanding, though.  Perhaps you can explain how you
> think this code should look?

My reading of the code was that we require order >= min_order to enter
the loop. Given that order doesn't change between the loop header and the
if (!order) check, then that must mean we can enter the loop body with
order == 0 and order >= min_order, which means that min_order is allowed
to be negative. That feels weird.

Am I barking up the wrong tree?

Will

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: [PATCH v2 1/2] dma/iommu: Add pgsize_bitmap confirmation in __iommu_dma_alloc_pages Doug Anderson <dianders@chromium.org> - 2016-04-05 19:10 +0200
  Re: [PATCH v2 1/2] dma/iommu: Add pgsize_bitmap confirmation in  __iommu_dma_alloc_pages Will Deacon <will.deacon@arm.com> - 2016-04-08 15:10 +0200
    Re: [PATCH v2 1/2] dma/iommu: Add pgsize_bitmap confirmation in __iommu_dma_alloc_pages Doug Anderson <dianders@chromium.org> - 2016-04-08 19:00 +0200
      Re: [PATCH v2 1/2] dma/iommu: Add pgsize_bitmap confirmation in __iommu_dma_alloc_pages Doug Anderson <dianders@chromium.org> - 2016-04-08 19:40 +0200
        Re: [PATCH v2 1/2] dma/iommu: Add pgsize_bitmap confirmation in  __iommu_dma_alloc_pages Yong Wu <yong.wu@mediatek.com> - 2016-04-11 09:50 +0200
      Re: [PATCH v2 1/2] dma/iommu: Add pgsize_bitmap confirmation in  __iommu_dma_alloc_pages Will Deacon <will.deacon@arm.com> - 2016-04-08 19:40 +0200

csiph-web