linux-kernel - Re: [PATCH v6 2/5] dma-buf: heaps: Add heap helpers

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: <CAF6AEGuKMu+=HYxmOPUL-5gkU1a1aqCxbx+E2ygYQqy4gmZ0Xw@mail.gmail.com>
Date:   Thu, 25 Jul 2019 08:23:51 -0700
From:   Rob Clark <robdclark@...il.com>
To:     Christoph Hellwig <hch@...radead.org>
Cc:     "Andrew F. Davis" <afd@...com>,
        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>,
        Hridya Valsaraju <hridya@...gle.com>
Subject: Re: [PATCH v6 2/5] dma-buf: heaps: Add heap helpers

On Thu, Jul 25, 2019 at 5:41 AM Christoph Hellwig <hch@...radead.org> wrote:
>
> On Wed, Jul 24, 2019 at 11:20:31AM -0400, Andrew F. Davis wrote:
> > Well then lets think on this. A given buffer can have 3 owners states
> > (CPU-owned, Device-owned, and Un-owned). These are based on the caching
> > state from the CPU perspective.
> >
> > If a buffer is CPU-owned then we (Linux) can write to the buffer safely
> > without worry that the data is stale or that it will be accessed by the
> > device without having been flushed. Device-owned buffers should not be
> > accessed by the CPU, and inter-device synchronization should be handled
> > by fencing as Rob points out. Un-owned is how a buffer starts for
> > consistency and to prevent unneeded cache operations on unwritten buffers.
>
> CPU owned also needs to be split into which mapping owns it - in the
> normal DMA this is the kernel direct mapping, but in dma-buf it seems
> the primary way of using it in kernel space is the vmap, in addition
> to that the mappings can also be exported to userspace, which is another
> mapping that is possibly not cache coherent with the kernel one.

Just for some history, dmabuf->vmap() is optional, and mostly added
for the benefit of drm/udl (usb display, where CPU needs to read out
and encode (?) the video stream.. most of the drm drivers are using
tmpfs to get backing pages, and if there is any kernel direct mapping
it is unused.

It is probably ok for any allocator that does care about a kernel
direct mapping to simply not implement vmap.

BR,
-R