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

Will Deacon
2016-04-08T13:07:40Z

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