> On Thu, Sep 20, 2018 at 12:08:28PM -0700, Max Filippov wrote:
> > I'm not familiar with the details of alloc_contig_range implementation, but
> > I don't see how gfp_mask is used to limit allocation to non-high memory.
> > So when alloc_contig_range gets start and end PFNs in high memory
> > (from the CMA region allocated in high memory) it just returns high memory
> > pages

Correct. alloc_contig_range doesn’t care where the PFNs are.  The
gpf_mask is completely ignored in this regard.

> > -- that's what I see.

On Fri, 21 Sep 2018 at 07:51, Christoph Hellwig <h...@lst.de> wrote:
> I can't see what prevents people from doing a CMA in high memory either,

That’s a feature. CMA can be configured such that different devices use
different regions. One use case is separation of devices; another is
devices with different address limits.

> which is bad as except for arm non of the callers handles it completely
> (and that includes xtensa, more below).
>
> CMA maintainers - is it intentional that CMA can be used to reserve and
> return highmem pages?

What Joonsoo said. I’ll just add that what you want to look at are invocations
of dma_contiguous_reserve. For xtensa it’s:

arch/xtensa/mm/init.c:  dma_contiguous_reserve(PFN_PHYS(max_low_pfn));

which means that CMA’s default region will be placed below max_low_pfn.
Undesired high memory CMA allocations on a given platform indicate that
platform’s init code incorrectly places CMA region or the region is incorrectly
configured in device tree.

-- 
Best regards
ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ
«If at first you don’t succeed, give up skydiving»
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Reply via email to