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: <CALAqxLVc475=eFSpJmYUE_82LWyR+bt1vWr-_0aGN=GPicPKVA@mail.gmail.com>
Date:   Fri, 15 Mar 2019 13:08:38 -0700
From:   John Stultz <john.stultz@...aro.org>
To:     Christoph Hellwig <hch@...radead.org>
Cc:     lkml <linux-kernel@...r.kernel.org>,
        Laura Abbott <labbott@...hat.com>,
        Benjamin Gaignard <benjamin.gaignard@...aro.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        Sumit Semwal <sumit.semwal@...aro.org>,
        Liam Mark <lmark@...eaurora.org>,
        Brian Starkey <Brian.Starkey@....com>,
        "Andrew F . Davis" <afd@...com>, Chenbo Feng <fengc@...gle.com>,
        Alistair Strachan <astrachan@...gle.com>,
        dri-devel <dri-devel@...ts.freedesktop.org>
Subject: Re: [RFC][PATCH 4/5 v2] dma-buf: heaps: Add CMA heap to dmabuf heapss

On Fri, Mar 15, 2019 at 2:06 AM Christoph Hellwig <hch@...radead.org> wrote:
>
> On Tue, Mar 05, 2019 at 12:54:32PM -0800, John Stultz wrote:
> > This adds a CMA heap, which allows userspace to allocate
> > a dma-buf of contiguous memory out of a CMA region.
>
> With my previous suggestion of DMA API usage you'd get CMA support for
> free in the system one instead of all this duplicate code..

Hey Christoph! Thanks for the review here! I'm still digesting your
comments, so apologies if I misunderstand.

On the point here, unless you're referring to some earlier suggestion
on a previous discussion (and not the system heap feedback), part of
the reason there are separate heaps is to allow Android to be able to
optimize where the allocations are coming from to best match the use
case. So they only want to allocate CMA backed dmabufs when the use
case has devices that require it, or they may even want to have
separate a CMA region reserved for a specific use case (like camera
buffers). Similarly for any future heap for allocating secure
dma-bufs.  So while in the implementation we can consolidate the code
more, but we'd still probably want to have separate heaps.

Does that make sense? Am I misinterpreting your feedback?

thanks
-john

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ