linux-kernel - Re: [PATCH v6 4/5] dma-buf: heaps: Add CMA heap to dmabuf heaps

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <0eae0024-1fdf-bd06-a8ff-1a41f0af3c69@ti.com>
Date:   Thu, 25 Jul 2019 09:31:50 -0400
From:   "Andrew F. Davis" <afd@...com>
To:     Christoph Hellwig <hch@...radead.org>
CC:     John Stultz <john.stultz@...aro.org>,
        lkml <linux-kernel@...r.kernel.org>,
        Laura Abbott <labbott@...hat.com>,
        Benjamin Gaignard <benjamin.gaignard@...aro.org>,
        Sumit Semwal <sumit.semwal@...aro.org>,
        Liam Mark <lmark@...eaurora.org>,
        Pratik Patel <pratikp@...eaurora.org>,
        Brian Starkey <Brian.Starkey@....com>,
        Vincent Donnefort <Vincent.Donnefort@....com>,
        Sudipto Paul <Sudipto.Paul@....com>,
        Xu YiPing <xuyiping@...ilicon.com>,
        "Chenfeng (puck)" <puck.chen@...ilicon.com>,
        butao <butao@...ilicon.com>,
        "Xiaqing (A)" <saberlily.xia@...ilicon.com>,
        Yudongbin <yudongbin@...ilicon.com>,
        Chenbo Feng <fengc@...gle.com>,
        Alistair Strachan <astrachan@...gle.com>,
        dri-devel <dri-devel@...ts.freedesktop.org>
Subject: Re: [PATCH v6 4/5] dma-buf: heaps: Add CMA heap to dmabuf heaps

On 7/25/19 8:50 AM, Christoph Hellwig wrote:
> On Wed, Jul 24, 2019 at 11:46:01AM -0400, Andrew F. Davis wrote:
>> https://patchwork.kernel.org/patch/10863957/
>>
>> It's actually a more simple heap type IMHO, but the logic inside is
>> incompatible with the system/CMA heaps, if you move any of their code
>> into the core framework then this heap stops working. Leading to out of
>> tree hacks on the core to get it back functional. I see the same for the
>> "complex" heaps with ION.
> 
> Well, this mostly is just another allocator (gen_pool).  And given that
> the whole dma-buf infrastucture assumes things are backed by pages we
> really shouldn't need much more than an alloc and a free callback (and
> maybe the pgprot to map it) and handle the rest in common code.
> 

But that's just it, dma-buf does not assume buffers are backed by normal
kernel managed memory, it is up to the buffer exporter where and when to
allocate the memory. The memory backed by this SRAM buffer does not have
the normal struct page backing. So moving the map, sync, etc functions
to common code would fail for this and many other heap types. This was a
major problem with Ion that prompted this new design.

Each heap type may need to do something different depending on its
backing memory, moving everything to common code that is common to
System and CMA heaps is would lead those being the only upstreamable heaps.

Andrew