linux-kernel - Re: [git pull] habanalabs pull request for kernel 5.15

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: <YSLYklow2ZAPqgK1@pendragon.ideasonboard.com>
Date:   Mon, 23 Aug 2021 02:06:58 +0300
From:   Laurent Pinchart <laurent.pinchart@...asonboard.com>
To:     Dave Airlie <airlied@...il.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jason Gunthorpe <jgg@...lanox.com>,
        Daniel Vetter <daniel.vetter@...ll.ch>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Oded Gabbay <ogabbay@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [git pull] habanalabs pull request for kernel 5.15

On Fri, Aug 20, 2021 at 04:48:18AM +1000, Dave Airlie wrote:
> On Fri, 20 Aug 2021 at 03:07, Greg KH wrote:
> > On Thu, Aug 19, 2021 at 02:02:09PM +0300, Oded Gabbay wrote:
> > > Hi Greg,
> > >
> > > This is habanalabs pull request for the merge window of kernel 5.15.
> > > The commits divide roughly 50/50 between adding new features, such
> > > as peer-to-peer support with DMA-BUF or signaling from within a graph,
> > > and fixing various bugs, small improvements, etc.
> >
> > Pulled and pushed out, thanks!
> 
> NAK for adding dma-buf or p2p support to this driver in the upstream
> kernel. There needs to be a hard line between
> "I-can't-believe-its-not-a-drm-driver" drivers which bypass our
> userspace requirements, and I consider this the line.
> 
> This driver was merged into misc on the grounds it wasn't really a
> drm/gpu driver and so didn't have to accept our userspace rules.
> 
> Adding dma-buf/p2p support to this driver is showing it really fits
> the gpu driver model and should be under the drivers/gpu rules since
> what are most GPUs except accelerators.
> 
> We are opening a major can of worms (some would say merging habanalabs
> driver opened it), but this places us in the situation that if a GPU
> vendor just claims their hw is a "vector" accelerator they can use
> Greg to bypass all the work that been done to ensure we have
> maintainability long term. I don't want drivers in the tree using
> dma-buf to interact with other drivers when we don't have access to a
> userspace project to validate the kernel driver assumptions.

I can only voice the strongest agreement here. This is a situation that
is only too familiar and that we're facing in the camera world as well.
For the past ten years, the camera community has worked hard to build
bridges with hardware vendors. The public development in the kernel tree
is only the visible part of the iceberg, lots of efforts have been put
in reaching out, teaching and helping. A few years ago the libcamera
project got started to offer a userspace framework to device vendors
where they can contribute code, similar to Mesa for graphics (and
related) acceleration.

I can't emphasize strongly enough how much effort it took to start
getting vendors on board, and the situation is still fragile at best. If
we now send a message that all of this can be bypassed by merging code
that ignores all rules in drivers/misc/, it would be ten years of
completely wasted work. Beside the technical impact, the effect on the
motivation of the kernel and userspace communities we have slowly built
over time would be catastrophic.

-- 
Regards,

Laurent Pinchart