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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20241024-giraffe-of-pastoral-hail-3141a9@houat>
Date: Thu, 24 Oct 2024 14:43:54 +0200
From: Maxime Ripard <mripard@...hat.com>
To: Nicolas Dufresne <nicolas@...fresne.ca>
Cc: John Stultz <jstultz@...gle.com>, 
	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

On Tue, Oct 22, 2024 at 01:58:47PM -0400, Nicolas Dufresne wrote:
> 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).

Yeah, that's one of the things we discussed at Plumbers too. My
point-of-view was that userspace also had no way to tell which kind of
buffers it would get. We settled down on the heap name providing those
semantics, and it resulted in:

https://lore.kernel.org/r/20240930144057.453751-1-mripard@kernel.org

> 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.

Yeah, that's another issue that needs to be tackled at some point indeed.

> 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.

Meh. The same argument could be said for v4l2 or DRM/KMS, and it never
bothered anyone.

Fortunately, we're tackling that issue as well:
https://lore.kernel.org/dri-devel/20241023075302.27194-1-maarten.lankhorst@linux.intel.com/

Maxime

Download attachment "signature.asc" of type "application/pgp-signature" (274 bytes)