linux-kernel - Re: [PATCH v3 0/2] dma-buf: heaps: Support carved-out heaps

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] [day] [month] [year] [list]

Message-ID: <20250425-refined-nano-vole-efe21e@houat>
Date: Fri, 25 Apr 2025 09:55:59 +0200
From: Maxime Ripard <mripard@...nel.org>
To: Rob Herring <robh@...nel.org>, Saravana Kannan <saravanak@...gle.com>, 
	Sumit Semwal <sumit.semwal@...aro.org>, Benjamin Gaignard <benjamin.gaignard@...labora.com>, 
	Brian Starkey <Brian.Starkey@....com>, John Stultz <jstultz@...gle.com>, 
	"T.J. Mercier" <tjmercier@...gle.com>, Christian König <christian.koenig@....com>
Cc: Mattijs Korpershoek <mkorpershoek@...nel.org>, 
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, linux-media@...r.kernel.org, 
	dri-devel@...ts.freedesktop.org, linaro-mm-sig@...ts.linaro.org
Subject: Re: [PATCH v3 0/2] dma-buf: heaps: Support carved-out heaps

Hi,

On Mon, Apr 07, 2025 at 06:29:06PM +0200, Maxime Ripard wrote:
> Hi,
> 
> This series is the follow-up of the discussion that John and I had some
> time ago here:
> 
> https://lore.kernel.org/all/CANDhNCquJn6bH3KxKf65BWiTYLVqSd9892-xtFDHHqqyrroCMQ@mail.gmail.com/
> 
> The initial problem we were discussing was that I'm currently working on
> a platform which has a memory layout with ECC enabled. However, enabling
> the ECC has a number of drawbacks on that platform: lower performance,
> increased memory usage, etc. So for things like framebuffers, the
> trade-off isn't great and thus there's a memory region with ECC disabled
> to allocate from for such use cases.
> 
> After a suggestion from John, I chose to first start using heap
> allocations flags to allow for userspace to ask for a particular ECC
> setup. This is then backed by a new heap type that runs from reserved
> memory chunks flagged as such, and the existing DT properties to specify
> the ECC properties.
> 
> After further discussion, it was considered that flags were not the
> right solution, and relying on the names of the heaps would be enough to
> let userspace know the kind of buffer it deals with.
> 
> Thus, even though the uAPI part of it has been dropped in this second
> version, we still need a driver to create heaps out of carved-out memory
> regions. In addition to the original usecase, a similar driver can be
> found in BSPs from most vendors, so I believe it would be a useful
> addition to the kernel.
> 
> I submitted a draft PR to the DT schema for the bindings used in this
> PR:
> https://github.com/devicetree-org/dt-schema/pull/138

One thing the discussion about the CMA heap naming[1] with John made me
realize is that if we have both a region that is exported as a
carved-out heap, and with devices pointing to it with reserved-memory,
we wouldn't use the same allocator in both cases.

It looks like we have four cases:

  - We have a shared-dma-pool region with the reusable property: the
    region is registered as a CMA area, the devices will allocate from
    that.

  - We have a shared-dma-pool region without the reusable property: the
    region is registered as a coherent DMA area, and the devices will
    allocate from that pool.

  - We have a restricted-dma-pool region, devices will allocate from
    swiotlb

  - We have any other region, we can do whatever.

So, the driver only supports the fourth case, and should be
significantly more complicated.

I'll work on that.

Maxime

1: https://lore.kernel.org/dri-devel/20250422191939.555963-1-jkangas@redhat.com/

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