linux-kernel - Re: [RESEND][PATCH v8 0/5] DMA-BUF Heaps (destaging ION)

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 for Android: free password hash cracker in your pocket

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

Message-ID: <a213760f-1f41-c4a3-7e38-8619898adecd@ti.com>
Date:   Wed, 16 Oct 2019 13:40:43 -0400
From:   "Andrew F. Davis" <afd@...com>
To:     Brian Starkey <Brian.Starkey@....com>
CC:     Ayan Halder <Ayan.Halder@....com>,
        Sumit Semwal <sumit.semwal@...aro.org>,
        Sudipto Paul <Sudipto.Paul@....com>,
        Vincent Donnefort <Vincent.Donnefort@....com>,
        Chenbo Feng <fengc@...gle.com>,
        Alistair Strachan <astrachan@...gle.com>,
        Liam Mark <lmark@...eaurora.org>,
        lkml <linux-kernel@...r.kernel.org>,
        Christoph Hellwig <hch@...radead.org>,
        DRI mailing list <dri-devel@...ts.freedesktop.org>,
        Hridya Valsaraju <hridya@...gle.com>, nd <nd@....com>,
        Pratik Patel <pratikp@...eaurora.org>
Subject: Re: [RESEND][PATCH v8 0/5] DMA-BUF Heaps (destaging ION)

On 10/14/19 5:07 AM, Brian Starkey wrote:
> Hi Andrew,
> 
> On Wed, Oct 09, 2019 at 02:27:15PM -0400, Andrew F. Davis wrote:
>> The CMA driver that registers these nodes will have to be expanded to
>> export them using this framework as needed. We do something similar to
>> export SRAM nodes:
>>
>> https://lkml.org/lkml/2019/3/21/575
>>
>> Unlike the system/default-cma driver which can be centralized in the
>> tree, these extra exporters will probably live out in other subsystems
>> and so are added in later steps.
>>
>> Andrew
> 
> I was under the impression that the "cma_for_each_area" loop in patch
> 4 would do that (add_cma_heaps). Is it not the case?
> 

For these cma nodes yes, I thought you meant reserved memory areas in
general.

Just as a side note, I'm not a huge fan of the cma_for_each_area() to
begin with, it seems a bit out of place when they could be selectively
added as heaps as needed. Not sure how that will work with cma nodes
specifically assigned to devices, seems like we could just steal their
memory space from userspace with this..

Andrew

> Thanks,
> -Brian
>