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: <CALAqxLUhot_nceaw5zpJ7QXcsfHNL8bOV-3MOeKu9c76Tfzx=g@mail.gmail.com>
Date:   Mon, 4 Nov 2019 11:34:19 -0800
From:   John Stultz <john.stultz@...aro.org>
To:     Sandeep Patil <sspatil@...gle.com>
Cc:     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>,
        Christoph Hellwig <hch@...radead.org>,
        Chenbo Feng <fengc@...gle.com>,
        Hridya Valsaraju <hridya@...gle.com>,
        Hillf Danton <hdanton@...a.com>,
        Dave Airlie <airlied@...il.com>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        sspatil+mutt@...gle.com, "Andrew F . Davis" <afd@...com>,
        Alistair Strachan <astrachan@...gle.com>
Subject: Re: [PATCH v14 2/5] dma-buf: heaps: Add heap helpers

On Sun, Nov 3, 2019 at 8:13 AM <sspatil@...gle.com> wrote:
> On Fri, Nov 01, 2019 at 09:42:35PM +0000, John Stultz wrote:
> > Add generic helper dmabuf ops for dma heaps, so we can reduce
> > the amount of duplicative code for the exported dmabufs.
> >
> > This code is an evolution of the Android ION implementation, so
> > thanks to its original authors and maintainters:
> >   Rebecca Schultz Zavin, Colin Cross, Laura Abbott, and others!
> >
> > Cc: Laura Abbott <labbott@...hat.com>
> > Cc: Benjamin Gaignard <benjamin.gaignard@...aro.org>
> > Cc: Sumit Semwal <sumit.semwal@...aro.org>
> > Cc: Liam Mark <lmark@...eaurora.org>
> > Cc: Pratik Patel <pratikp@...eaurora.org>
> > Cc: Brian Starkey <Brian.Starkey@....com>
> > Cc: Vincent Donnefort <Vincent.Donnefort@....com>
> > Cc: Sudipto Paul <Sudipto.Paul@....com>
> > Cc: Andrew F. Davis <afd@...com>
> > Cc: Christoph Hellwig <hch@...radead.org>
> > Cc: Chenbo Feng <fengc@...gle.com>
> > Cc: Alistair Strachan <astrachan@...gle.com>
> > Cc: Hridya Valsaraju <hridya@...gle.com>
> > Cc: Sandeep Patil <sspatil@...gle.com>
> > Cc: Hillf Danton <hdanton@...a.com>
> > Cc: Dave Airlie <airlied@...il.com>
> > Cc: dri-devel@...ts.freedesktop.org
> > Reviewed-by: Benjamin Gaignard <benjamin.gaignard@...aro.org>
> > Reviewed-by: Brian Starkey <brian.starkey@....com>
> > Acked-by: Laura Abbott <labbott@...hat.com>
> > Tested-by: Ayan Kumar Halder <ayan.halder@....com>
> > Signed-off-by: John Stultz <john.stultz@...aro.org>
>
> I have one question and a naming suggestin below (sorry).
>
> Acked-by: Sandeep Patil <sspatil@...roid.com>

> > +
> > +static void dma_heap_buffer_vmap_put(struct heap_helper_buffer *buffer)
> > +{
> > +     if (!--buffer->vmap_cnt) {
>
> nit: just checking here cause I don't know the order in which vmap_get() and
> vmap_put() is expected to be called from dmabuf, the manual refcounting
> based map/unmap is ok?
>
> I know ion had this for a while and it worked fine over the years, but I
> don't know if anybody saw any issues with it.
> > +             vunmap(buffer->vaddr);
> > +             buffer->vaddr = NULL;
> > +     }
> > +}
> > +




> > +#ifndef _HEAP_HELPERS_H
> > +#define _HEAP_HELPERS_H
> > +
> > +#include <linux/dma-heap.h>
> > +#include <linux/list.h>
> > +
> > +/**
> > + * struct heap_helper_buffer - helper buffer metadata
> > + * @heap:            back pointer to the heap the buffer came from
> > + * @dmabuf:          backing dma-buf for this buffer
> > + * @size:            size of the buffer
> > + * @flags:           buffer specific flags
> nit: Are thee dmabuf flags, or dmabuf_heap specific / allocation related flags?

Good point. They were going to be for the generic flags but as there's
no supported flags yet, there's no reason to track that in the helper
code.

I'll drop it

> > + * @priv_virt                pointer to heap specific private value
> nit: text looks misaligned (or is it my editor?)

Looks ok to me in vim.


> > + * @lock             mutext to protect the data in this structure
> > + * @vmap_cnt         count of vmap references on the buffer
> > + * @vaddr            vmap'ed virtual address
> > + * @pagecount                number of pages in the buffer
> > + * @pages            list of page pointers
> > + * @attachments              list of device attachments
> ditto
> > + *
> > + * @free             heap callback to free the buffer
> > + */
> > +struct heap_helper_buffer {
> /bikeshed/
> s/heap_helper_buffer/dma_heap_buffer ?
>
> The "heap helper buffer" doesn't really convey what it is.

So its the helper structure that is used with all the helper
functions. Since other dmabuf heaps don't have to use the helper
infrastructure, they wouldn't need this structure, so I don't want to
name it too generically to confuse folks.

thanks
-john

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ