linux-kernel - Re: Requirements to merge new heaps in the kernel

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: <f8831b4e658b19a1df4cc02449bb74d730908de6.camel@ndufresne.ca>
Date: Tue, 22 Oct 2024 13:58:47 -0400
From: Nicolas Dufresne <nicolas@...fresne.ca>
To: John Stultz <jstultz@...gle.com>, Maxime Ripard <mripard@...hat.com>
Cc: Sumit Semwal <sumit.semwal@...aro.org>, Benjamin Gaignard
 <benjamin.gaignard@...labora.com>, Brian Starkey <Brian.Starkey@....com>, 
 "T.J. Mercier" <tjmercier@...gle.com>, Christian König
 <christian.koenig@....com>,  linux-media@...r.kernel.org,
 dri-devel@...ts.freedesktop.org,  linaro-mm-sig@...ts.linaro.org,
 linux-kernel@...r.kernel.org
Subject: Re: Requirements to merge new heaps in the kernel

Hi,

Le mardi 22 octobre 2024 à 09:19 -0700, John Stultz a écrit :
> On Tue, Oct 22, 2024 at 1:38 AM Maxime Ripard <mripard@...hat.com> wrote:
> > 
> > I wanted to follow-up on the discussion we had at Plumbers with John and
> > T.J. about (among other things) adding new heaps to the kernel.
> > 
> > I'm still interested in merging a carve-out driver[1], since it seems to be
> > in every vendor BSP and got asked again last week.
> > 
> > I remember from our discussion that for new heap types to be merged, we
> > needed a kernel use-case. Looking back, I'm not entirely sure how one
> > can provide that given that heaps are essentially facilities for
> > user-space.
> > 
> > Am I misremembering or missing something? What are the requirements for
> > you to consider adding a new heap driver?
> 
> It's basically the same as the DRM subsystem rules.
> https://docs.kernel.org/gpu/drm-uapi.html#open-source-userspace-requirements
> ie: There has to be opensource user for it, and the user has to be
> more significant than a "toy" implementation (which can be a bit
> subjective and contentious when trying to get out of a chicken and egg
> loop).

If there is a generic logic to decide to use a carve-out when using some
specific device on specific platform, it would not be a problem to make
userspace for it. I'm happy to take DMABuf patches in GStreamer notably (which
could greatly help ensuring zero-copy path).

But so far, all the proposals was just a base allocator, no way to know when to
use it and for which device. The actual mapping of heaps and device was left to
userspace, which to be honest would only work with a userspace Linux Allocator
library, with userspace drivers, or inside mesa if the devices are GPUs/NPUs.
This is a project Laurent Pinchard have hosted a workshop about during XDC.

Nicolas

p.s. libcamera have device specific knowledge, and could of course be a shorter
term user. Note that major distro are not happy that there is no memory
accounting for dmabuf, bypassing sandboxes and limits.