summaryrefslogtreecommitdiffstats
path: root/Documentation/userspace-api/dma-buf-heaps.rst
diff options
context:
space:
mode:
authorSven Schnelle <svens@linux.ibm.com>2026-09-09 11:29:53 +0200
committerMasami Hiramatsu (Google) <mhiramat@kernel.org>2026-09-10 08:43:35 +0900
commitd22c3e0088e85be8131f7a9283f759cdbb20726d (patch)
tree9668df2aa27b26f850d3ba5ba1287e443803675c /Documentation/userspace-api/dma-buf-heaps.rst
downloadlinux-stable-d22c3e0088e85be8131f7a9283f759cdbb20726d.tar.gz
linux-stable-d22c3e0088e85be8131f7a9283f759cdbb20726d.zip
selftests/ftrace: Fix unique symbol check in kprobe_non_uniq_symbol.tcgrafted
The current regex also matches symbols in modules, which makes the test fail on s390 where name_show is present only once in the kernel, but also multiple times in modules: 000001b1401cdc20 t name_show 000001b0c05e6c40 t name_show [mdev] 000001b0c0495f30 t name_show [i2c_core] Fix this by changing the regular expression to only match the function name. Link: https://lore.kernel.org/all/20260909092954.2200558-1-svens@linux.ibm.com/ Fixes: 03b80ff8023a ("selftests/ftrace: Add new test case which checks non unique symbol") Signed-off-by: Sven Schnelle <svens@linux.ibm.com> Reviewed-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Diffstat (limited to 'Documentation/userspace-api/dma-buf-heaps.rst')
-rw-r--r--Documentation/userspace-api/dma-buf-heaps.rst74
1 files changed, 74 insertions, 0 deletions
diff --git a/Documentation/userspace-api/dma-buf-heaps.rst b/Documentation/userspace-api/dma-buf-heaps.rst
new file mode 100644
index 000000000..f56b743cd
--- /dev/null
+++ b/Documentation/userspace-api/dma-buf-heaps.rst
@@ -0,0 +1,74 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==============================
+Allocating dma-buf using heaps
+==============================
+
+Dma-buf Heaps are a way for userspace to allocate dma-buf objects. They are
+typically used to allocate buffers from a specific allocation pool, or to share
+buffers across frameworks.
+
+Heaps
+=====
+
+A heap represents a specific allocator. The Linux kernel currently supports the
+following heaps:
+
+ - The ``system`` heap allocates virtually contiguous, cacheable, buffers.
+
+ - The ``system_cc_shared`` heap allocates virtually contiguous, cacheable,
+ buffers using shared (decrypted) memory. It is only present on
+ confidential computing (CoCo) VMs where memory encryption is active
+ (e.g., AMD SEV, Intel TDX). The allocated pages have the encryption
+ bit cleared, making them accessible for device DMA without TDISP
+ support. On non-CoCo VM configurations, this heap is not registered.
+
+ - The ``default_cma_region`` heap allocates physically contiguous,
+ cacheable, buffers. Only present if a CMA region is present. Such a
+ region is usually created either through the kernel commandline
+ through the ``cma`` parameter, a memory region Device-Tree node with
+ the ``linux,cma-default`` property set, or through the
+ ``CMA_SIZE_MBYTES`` or ``CMA_SIZE_PERCENTAGE`` Kconfig options. Prior
+ to Linux 6.17, its name wasn't stable and could be called
+ ``reserved``, ``linux,cma``, or ``default-pool``, depending on the
+ platform.
+
+ - A heap will be created for each reusable region in the device tree
+ with the ``shared-dma-pool`` compatible, using the full device tree
+ node name as its name. The buffer semantics are identical to
+ ``default-cma-region``.
+
+Naming Convention
+=================
+
+``dma-buf`` heaps name should meet a number of constraints:
+
+- The name must be stable, and must not change from one version to the other.
+ Userspace identifies heaps by their name, so if the names ever change, we
+ would be likely to introduce regressions.
+
+- The name must describe the memory region the heap will allocate from, and
+ must uniquely identify it in a given platform. Since userspace applications
+ use the heap name as the discriminant, it must be able to tell which heap it
+ wants to use reliably if there's multiple heaps.
+
+- The name must not mention implementation details, such as the allocator. The
+ heap driver will change over time, and implementation details when it was
+ introduced might not be relevant in the future.
+
+- The name should describe properties of the buffers that would be allocated.
+ Doing so will make heap identification easier for userspace. Such properties
+ are:
+
+ - ``contiguous`` for physically contiguous buffers;
+
+ - ``protected`` for encrypted buffers not accessible the OS;
+
+- The name may describe intended usage. Doing so will make heap identification
+ easier for userspace applications and users.
+
+For example, assuming a platform with a reserved memory region located
+at the RAM address 0x42000000, intended to allocate video framebuffers,
+physically contiguous, and backed by the CMA kernel allocator, good
+names would be ``memory@42000000-contiguous`` or ``video@42000000``, but
+``cma-video`` wouldn't.