Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

20 participants
6287 discussions

by Alex Morgan

ghost mystery recovery Hacker in 2026 ghost mystery recovery Hacker for 2026 include ghost mystery Recovery Hacker And which utilize blockchain forensics and legal strategies to recover stolen or lost assets. These firms specialize in tracing funds, working with law enforcement, and providing expert testimony to freeze assets. ghost mystery recovery Hacker Highly rated for 2026 for using AI-powered tools to trace funds across exchanges and privacy coins, with a focus on scams and hacked wallets. Email address: support@ ghostmysteryrecovery. c om WhatsApp on (+44) 7480 061765 Website; ghostmysteryrecovery. c om

2 hours, 44 minutes

(no subject)

by Alex Morgan

2 hours, 45 minutes

Re: [PATCH v2] dma-buf: heaps: system: document system_cc_shared heap

by Sumit Semwal

Hello Jiri, On Tue, 7 Apr 2026 at 14:56, Jiri Pirko <jiri(a)resnulli.us> wrote: > > 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> > Reviewed-by: T.J.Mercier <tjmercier(a)google.com> Thank you for the patch! Marek: Since you're taking the dependent patches through your tree, could you please use: Acked-by: Sumit Semwal <sumit.semwal(a)linaro.org> and take this as well? Thanks and Best regards, Sumit. > --- > Documentation/userspace-api/dma-buf-heaps.rst | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/Documentation/userspace-api/dma-buf-heaps.rst b/Documentation/userspace-api/dma-buf-heaps.rst > index 05445c83b79a..f56b743cdb36 100644 > --- a/Documentation/userspace-api/dma-buf-heaps.rst > +++ b/Documentation/userspace-api/dma-buf-heaps.rst > @@ -16,6 +16,13 @@ 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 > -- > 2.51.1 >

13 hours, 11 minutes

maine coon kittens for sale united states

by Chong Criston

15 hours, 59 minutes

ginger maine coon kittens for sale united states

by Chong Criston

16 hours

maine coon kittens for sale united states

by Chong Criston

16 hours, 2 minutes

maine coon kittens for sale united states cheap

by Chong Criston

16 hours, 2 minutes

maine coon kittens for sale united states price

by Chong Criston

16 hours, 3 minutes

maine coon kittens for sale united states

by Chong Criston

16 hours, 4 minutes

Re: [PATCH] dma-fence: Move signalling tracepoint to before ops detach

by Christian König

On 4/9/26 15:58, Tvrtko Ursulin wrote: > > On 31/03/2026 08:49, Boris Brezillon wrote: >> On Mon, 30 Mar 2026 14:36:23 +0100 >> Tvrtko Ursulin <tvrtko.ursulin(a)igalia.com> wrote: >> >>> Move the signalling tracepoint to before fence->ops are reset otherwise >>> tracepoint will dereference a null pointer. >> >> I suspect other trace points are impacted too >> (trace_dma_fence_destroy() is, at the very least). > > Indeed. I wonder why that did not trigger for me, while the one I fix here was an insta-crash... You need to actually enable the trace points and at least for the destroy one nobody is usually interested in that. > > To fix trace_dma_fence_destroy I think we need a new tracepoint definition ie. move it away from the existing event class - make it just log the context and seqno. > > Anyone has a better idea? The idea of tracing without accessing fence->ops sounds valid to me. Alternatively we could call dma_fence_timeline_name() and dma_fence_driver_name() from the tracepoint as well, but that means the tracepoints now require a RCU read side lock. Regards, Christian. > > Regards, > > Tvrtko > >>> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin(a)igalia.com> >>> Fixes: 541c8f2468b9 ("dma-buf: detach fence ops on signal v3") >>> Cc: Christian König <christian.koenig(a)amd.com> >>> Cc: Philipp Stanner <phasta(a)kernel.org> >>> Cc: Boris Brezillon <boris.brezillon(a)collabora.com> >>> Cc: linux-media(a)vger.kernel.org >>> Cc: linaro-mm-sig(a)lists.linaro.org >>> --- >>> drivers/dma-buf/dma-fence.c | 3 ++- >>> 1 file changed, 2 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c >>> index 1826ba73094c..1c1eaecaf1b0 100644 >>> --- a/drivers/dma-buf/dma-fence.c >>> +++ b/drivers/dma-buf/dma-fence.c >>> @@ -363,6 +363,8 @@ void dma_fence_signal_timestamp_locked(struct dma_fence *fence, >>> &fence->flags))) >>> return; >>> + trace_dma_fence_signaled(fence); >>> + >>> /* >>> * When neither a release nor a wait operation is specified set the ops >>> * pointer to NULL to allow the fence structure to become independent >>> @@ -377,7 +379,6 @@ void dma_fence_signal_timestamp_locked(struct dma_fence *fence, >>> fence->timestamp = timestamp; >>> set_bit(DMA_FENCE_FLAG_TIMESTAMP_BIT, &fence->flags); >>> - trace_dma_fence_signaled(fence); >>> list_for_each_entry_safe(cur, tmp, &cb_list, node) { >>> INIT_LIST_HEAD(&cur->node); >> >

16 hours, 33 minutes

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig