linux-kernel - Re: [PATCH v14 1/5] dma-buf: Add dma-buf heaps framework

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: <CAPM=9tydXxV-6++HkkA+JX9GPWE1sN_8CGVCVn-Mwfgfzcn=hg@mail.gmail.com>
Date:   Tue, 5 Nov 2019 02:58:17 +1000
From:   Dave Airlie <airlied@...il.com>
To:     Brian Starkey <Brian.Starkey@....com>
Cc:     John Stultz <john.stultz@...aro.org>,
        lkml <linux-kernel@...r.kernel.org>,
        "Andrew F. Davis" <afd@...com>, 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>,
        Vincent Donnefort <Vincent.Donnefort@....com>,
        Sudipto Paul <Sudipto.Paul@....com>,
        Christoph Hellwig <hch@...radead.org>,
        Chenbo Feng <fengc@...gle.com>,
        Alistair Strachan <astrachan@...gle.com>,
        Hridya Valsaraju <hridya@...gle.com>,
        Sandeep Patil <sspatil@...gle.com>,
        Hillf Danton <hdanton@...a.com>,
        "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        nd <nd@....com>
Subject: Re: [PATCH v14 1/5] dma-buf: Add dma-buf heaps framework

On Mon, 4 Nov 2019 at 20:24, Brian Starkey <Brian.Starkey@....com> wrote:
>
> Hi John,
>
> On Fri, Nov 01, 2019 at 09:42:34PM +0000, John Stultz wrote:
> > From: "Andrew F. Davis" <afd@...com>
> >
> > This framework allows a unified userspace interface for dma-buf
> > exporters, allowing userland to allocate specific types of memory
> > for use in dma-buf sharing.
> >
> > Each heap is given its own device node, which a user can allocate
> > a dma-buf fd from using the DMA_HEAP_IOC_ALLOC.
> >
> > Additionally should the interface grow in the future, we have a
> > DMA_HEAP_IOC_GET_FEATURES ioctl which can return future feature
> > flags.
>
> The userspace patch doesn't use this - and there's no indication of
> what it's intended to allow in the future. I missed the discussion
> about it, do you have a link?
>
> I thought the preferred approach was to add the new ioctl only when we
> need it, and new userspace on old kernels will get "ENOSYS" to know
> that the kernel doesn't support it.

This works once, expand the interface 3 or 4 times with no features
ioctl, and you start being hostile to userspace, which feature does
ENOSYS mean isn't supported etc.

Next userspace starts to rely on kernel version, but then someone
backports a feature, down the rabbit hole we go.

Be nice to userspace give them a features ioctl they can use to figure
out in advance which of the 4 uapis the kernel supports.

Dave.