linux-kernel - Re: [PATCH v2 1/2] drivers: dma-coherent: Fix dev->cma_area vs dev->dma

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20170711141937.GA12884@lst.de>
Date:   Tue, 11 Jul 2017 16:19:37 +0200
From:   Christoph Hellwig <hch@....de>
To:     Robin Murphy <robin.murphy@....com>
Cc:     Vladimir Murzin <vladimir.murzin@....com>,
        Christoph Hellwig <hch@....de>,
        Vitaly Kuzmichev <vitaly_kuzmichev@...tor.com>,
        gregkh@...uxfoundation.org, m.szyprowski@...sung.com,
        linux-kernel@...r.kernel.org, linux-next@...r.kernel.org,
        "George G. Davis" <george_davis@...tor.com>
Subject: Re: [PATCH v2 1/2] drivers: dma-coherent: Fix dev->cma_area vs
        dev->dma_mem breakage

On Fri, Jul 07, 2017 at 05:06:52PM +0100, Robin Murphy wrote:
> I don't think we need to go that far, I reckon it would be clear enough
> to just split the per-device vs. global pool interfaces, something like
> I've sketched out below (such that the ops->alloc implementation calls
> dma_alloc_from_global_coherent() if dma_alloc_from_contiguous() fails).
> 
> If anyone wants to take that and run with it, feel free.

I like this basic idea.  It also fits into one of my plans for the
4.14 merge window - I want to enhance the lib/dma-noop.c so that
it can use different allocators and mapping helpers, e.g. for
the allocators what makes sense is:

 (1) simple page allocator (as-is)
 (2) CMA
 (3) swiotlb
 (4) the OF coherent allocator from your draft patch

and then for the mapping into phys space we can use

 (1) virto_to_phys (as-is)
 (2) arch helper (e.g. like done in mips plat support)
 (3) maybe some common form of ioremap / vmap instead of various
     duplicates

With that we should be able to cosolidate most direct mapped
dma_ops for architectures that do not require cache flushing into
common code.  As a next step we could think about useful cache
flushing hooks.