dma_buf_put() may drop the final file reference via fput(), which
can free the dma-buf. The new tracepoint invocation was added
after fput(), and DMA_BUF_TRACE() dereferences dmabuf and takes
dmabuf->name_lock.
This leads to a use-after-free on the final put, visible for
example as a spinlock bad magic fault on a poisoned 0x6b6b6b...
lock.
Move the dma_buf_put tracepoint before fput().
Reported-by: Janusz Krzysztofik <janusz.krzysztofik(a)linux.intel.com>
Fixes: 281a22631423 ("dma-buf: add some tracepoints to debug.")
Signed-off-by: Andi Shyti <andi.shyti(a)linux.intel.com>
Cc: Xiang Gao <gaoxiang17(a)xiaomi.com>
Cc: Christian König <christian.koenig(a)amd.com>
---
Hi,
I believe this patch fixes the issue reported by Janusz, I haven't
tested it. Perhaps we can add some more checks in DMA_BUF_TRACE.
Thanks,
Andi
drivers/dma-buf/dma-buf.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index a202a308c079..b72932c57cb9 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -845,9 +845,8 @@ void dma_buf_put(struct dma_buf *dmabuf)
if (WARN_ON(!dmabuf || !dmabuf->file))
return;
- fput(dmabuf->file);
-
DMA_BUF_TRACE(trace_dma_buf_put, dmabuf);
+ fput(dmabuf->file);
}
EXPORT_SYMBOL_NS_GPL(dma_buf_put, "DMA_BUF");
--
2.53.0
From: Jiri Pirko <jiri(a)nvidia.com>
Document the system_cc_shared dma-buf heap that was introduced
recently. Describe its purpose, availability conditions and
relation to confidential computing VMs.
Signed-off-by: Jiri Pirko <jiri(a)nvidia.com>
---
Documentation/userspace-api/dma-buf-heaps.rst | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/userspace-api/dma-buf-heaps.rst b/Documentation/userspace-api/dma-buf-heaps.rst
index 05445c83b79a..591732393e7d 100644
--- a/Documentation/userspace-api/dma-buf-heaps.rst
+++ b/Documentation/userspace-api/dma-buf-heaps.rst
@@ -16,6 +16,14 @@ 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 VMs 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
--
2.51.1
Safeguard is not just another name in the crowded field of cryptocurrency recovery; they are renowned for their effectiveness and expertise in tracing lost funds. Their team comprises skilled professionals who understand the intricate workings of blockchain technology and the tactics employed by online scammers. This specialized knowledge enables them to devise tailored strategies to recover your assets.
Email,.. safeguardbitcoin(a)consultant.com
WhatsApp,.. +44 7426 168300
Web:., https://safeguardbitcoin.wixsite.com/safeguard-bitcoin--1
Hi,
I just came across this commit while researching something else.
Original patch had too few context lines, so I here's the diff with `-U10`.
On 3/18/25 20:22, Daniel Almeida wrote:
> From: Asahi Lina <lina(a)asahilina.net>
>
> Since commit 21aa27ddc582 ("drm/shmem-helper: Switch to reservation
> lock"), the drm_gem_shmem_vmap and drm_gem_shmem_vunmap functions
> require that the caller holds the DMA reservation lock for the object.
> Add lockdep assertions to help validate this.
There were already lockdep assertions...
> Signed-off-by: Asahi Lina <lina(a)asahilina.net>
> Signed-off-by: Daniel Almeida <daniel.almeida(a)collabora.com>
> Reviewed-by: Christian König <christian.koenig(a)amd.com>
> Signed-off-by: Lyude Paul <lyude(a)redhat.com>
> Link: https://lore.kernel.org/r/20250318-drm-gem-shmem-v1-1-64b96511a84f@collabor…
> ---
> drivers/gpu/drm/drm_gem_shmem_helper.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c b/drivers/gpu/drm/drm_gem_shmem_helper.c
> index aa43265f4f4f..0b41f0346bad 100644
> --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> @@ -341,20 +341,22 @@ EXPORT_SYMBOL_GPL(drm_gem_shmem_unpin);
> *
> * Returns:
> * 0 on success or a negative error code on failure.
> */
> int drm_gem_shmem_vmap_locked(struct drm_gem_shmem_object *shmem,
> struct iosys_map *map)
> {
> struct drm_gem_object *obj = &shmem->base;
> int ret = 0;
>
> + dma_resv_assert_held(obj->resv);
> +
> if (drm_gem_is_imported(obj)) {
> ret = dma_buf_vmap(obj->dma_buf, map);
> } else {
> pgprot_t prot = PAGE_KERNEL;
>
> dma_resv_assert_held(shmem->base.resv);
... right here, and
> if (refcount_inc_not_zero(&shmem->vmap_use_count)) {
> iosys_map_set_vaddr(map, shmem->vaddr);
> return 0;
> @@ -401,20 +403,22 @@ EXPORT_SYMBOL_GPL(drm_gem_shmem_vmap_locked);
> * drops to zero.
> *
> * This function hides the differences between dma-buf imported and natively
> * allocated objects.
> */
> void drm_gem_shmem_vunmap_locked(struct drm_gem_shmem_object *shmem,
> struct iosys_map *map)
> {
> struct drm_gem_object *obj = &shmem->base;
>
> + dma_resv_assert_held(obj->resv);
> +
> if (drm_gem_is_imported(obj)) {
> dma_buf_vunmap(obj->dma_buf, map);
> } else {
> dma_resv_assert_held(shmem->base.resv);
...here.
> if (refcount_dec_and_test(&shmem->vmap_use_count)) {
> vunmap(shmem->vaddr);
> shmem->vaddr = NULL;
>
> drm_gem_shmem_unpin_locked(shmem);
Or were those insufficient for some reason? If so, should we keep both
of them, or should the older ones have been removed?
Bence
Hi,
The recent introduction of heaps in the optee driver [1] made possible
the creation of heaps as modules.
It's generally a good idea if possible, including for the already
existing system and CMA heaps.
The system one is pretty trivial, the CMA one is a bit more involved,
especially since we have a call from kernel/dma/contiguous.c to the CMA
heap code. This was solved by turning the logic around and making the
CMA heap call into the contiguous DMA code.
Let me know what you think,
Maxime
1: https://lore.kernel.org/dri-devel/20250911135007.1275833-4-jens.wiklander@l…
Signed-off-by: Maxime Ripard <mripard(a)kernel.org>
---
Changes in v4:
- Fix compilation failure
- Rework to take into account OF_RESERVED_MEM
- Fix regression making the default CMA area disappear if not created
through the DT
- Added some documentation and comments
- Link to v3: https://lore.kernel.org/r/20260303-dma-buf-heaps-as-modules-v3-0-24344812c7…
Changes in v3:
- Squashed cma_get_name and cma_alloc/release patches
- Fixed typo in Export dev_get_cma_area commit title
- Fixed compilation failure with DMA_CMA but not OF_RESERVED_MEM
- Link to v2: https://lore.kernel.org/r/20260227-dma-buf-heaps-as-modules-v2-0-454aee7e06…
Changes in v2:
- Collect tags
- Don't export dma_contiguous_default_area anymore, but export
dev_get_cma_area instead
- Mentioned that heap modules can't be removed
- Link to v1: https://lore.kernel.org/r/20260225-dma-buf-heaps-as-modules-v1-0-2109225a09…
---
Maxime Ripard (8):
dma: contiguous: Turn heap registration logic around
dma: contiguous: Make dev_get_cma_area() a proper function
dma: contiguous: Make dma_contiguous_default_area static
dma: contiguous: Export dev_get_cma_area()
mm: cma: Export cma_alloc(), cma_release() and cma_get_name()
dma-buf: heaps: Export mem_accounting parameter
dma-buf: heaps: cma: Turn the heap into a module
dma-buf: heaps: system: Turn the heap into a module
drivers/dma-buf/dma-heap.c | 1 +
drivers/dma-buf/heaps/Kconfig | 4 +--
drivers/dma-buf/heaps/cma_heap.c | 22 +++----------
drivers/dma-buf/heaps/system_heap.c | 5 +++
include/linux/dma-buf/heaps/cma.h | 16 ---------
include/linux/dma-map-ops.h | 14 ++++----
kernel/dma/contiguous.c | 66 +++++++++++++++++++++++++++++++++----
mm/cma.c | 3 ++
8 files changed, 82 insertions(+), 49 deletions(-)
---
base-commit: c081b71f11732ad2c443f170ab19c3ebe8a1a422
change-id: 20260225-dma-buf-heaps-as-modules-1034b3ec9f2a
Best regards,
--
Maxime Ripard <mripard(a)kernel.org>