Linaro-mm-sig February 2026

linaro-mm-sig@lists.linaro.org

129 participants
1795 discussions

[PATCH 0/5] dma-buf: heaps: system: add an option to allocate explicitly decrypted memory

by Jiri Pirko

From: Jiri Pirko <jiri(a)nvidia.com> Confidential computing (CoCo) VMs/guests, such as AMD SEV and Intel TDX, run with encrypted/protected memory which creates a challenge for devices that do not support DMA to it (no TDISP support). For kernel-only DMA operations, swiotlb bounce buffering provides a transparent solution by copying data through decrypted memory. However, the only way to get this memory into userspace is via the DMA API's dma_alloc_pages()/dma_mmap_pages() type interfaces which limits the use of the memory to a single DMA device, and is incompatible with pin_user_pages(). These limitations are particularly problematic for the RDMA subsystem which makes heavy use of pin_user_pages() and expects flexible memory usage between many different DMA devices. This patch series enables userspace to explicitly request decrypted (shared) memory allocations from the dma-buf system heap. Userspace can mmap this memory and pass the dma-buf fd to other existing importers such as RDMA or DRM devices to access the memory. The DMA API is improved to allow the dma heap exporter to DMA map the shared memory to each importing device. Jiri Pirko (5): dma-mapping: avoid random addr value print out on error path dma-mapping: introduce DMA_ATTR_CC_DECRYPTED for pre-decrypted memory dma-buf: heaps: use designated initializer for exp_info dma-buf: heaps: allow heap to specify valid heap flags dma-buf: heaps: system: add an option to allocate explicitly decrypted memory drivers/dma-buf/dma-heap.c | 5 +- drivers/dma-buf/heaps/cma_heap.c | 7 ++- drivers/dma-buf/heaps/system_heap.c | 96 ++++++++++++++++++++++++++--- include/linux/dma-heap.h | 3 + include/linux/dma-mapping.h | 7 +++ include/trace/events/dma.h | 3 +- include/uapi/linux/dma-heap.h | 12 +++- kernel/dma/direct.h | 14 ++++- 8 files changed, 128 insertions(+), 19 deletions(-) -- 2.51.1

5 months, 2 weeks

Top Legitimate Crypto Recovery Company iForce Hacker Recovery

by freddie70271＠gmail.com

I spent weeks wondering if a lost seed phrase could ever be restored. While researching, I came across iForce Hacker Recovery, a cryptocurrency recovery company that assisted me in regaining my seed phrase, wallet access, and monies that had been stolen by crooks. I was depressed and hopeless until their skilled and supportive crew walked me through the procedure. I'm grateful to them for helping me regain everything. I wholeheartedly recommend iForce Hacker Recovery to anyone who requires dependable crypto recovery assistance. Website: http: // iforcehackers. co m WhatsApp:+1 240-803-3706. Email: iforcehk @ consultant.com

5 months, 2 weeks

HOW TO FIND A LEGITIMATE CRYPTO RECOVERY EXPERT; Contact iFORCE HACKER RECOVERY

by wsuttles6＠gmail.com

iForce Hacker Recovery are seasoned cryptocurrency specialists recognized for excellence in bitcoin fraud recovery. Their team has extensive knowledge of blockchain technology and the quickly changing cryptocurrency ecosystem, and they have a track record of assisting clients in recovering lost or stolen assets. They can successfully manage complex recovery cases because of their competence. There is still hope if you have been the victim of a cryptocurrency scam because iForce Hacker Recovery is ready to assist you in regaining the money that has been lost. Website: ht tps://iforcehackers. co m WhatsApp: +1 240-803-3706 Email: iforcehk @ consultant. c om

5 months, 2 weeks

Is iFORCE HACKER RECOVERY a Genuine, Real, Legit Recovery Company?

by Samantha Williams

iForce Hacker Recovery is widely recognized as one of the top bitcoin recovery services, known for its dedication to recovering lost or stolen bitcoins. Their recovery process uses advanced blockchain analytics and forensic techniques to help victims trace and recover their digital assets. The team, made up of experts in blockchain technology and regulatory compliance, offers personalized solutions for issues like fraud, scams, and hacking. Homepage; https://iforcehackers.com/ Email; iforcehk(a)consultant.com Text-whatsapp; +1 (240) 803. 37 06

5 months, 2 weeks

Best Crypto Recovery Service Reviews - iFORCE HACKER RECOVERY

by Nora Valera

As a realtor accustomed to high-value transactions, nothing prepared me for the fear of losing access to my Bitcoin wallet, which included $1 million saved for retirement. After mistakenly removing the app, discovering faulty backups, and forgetting my recovery phrase, I was frantic. I contacted iFORCE HACKER RECOVERY after receiving a suggestion from a friend. Though suspicious at first, their professionalism, compassion, clear communication, and meticulous approach convinced me. After ten long days, my wallet was completely retrieved. They not only returned my Bitcoin, but also my peace of mind and future. Contact Information: Website: ht tps: // iforcehackers .co m . Email: iforcehk @ consultant .co m WhatsApp: +1 240-803-3706

5 months, 2 weeks

How Can I Contact a Cryptocurrency Recovery Company? Visit iFORCE HACKER RECOVERY

by Harry Jones

I realize how volatile and thrilling cryptocurrency can be. After joining a Telegram-based service, I made consistent profits for six months before unexpected faults deprived me of approximately $343,000. Withdrawal blunders, little help, and rising dread kept me stuck. I then discovered iForce Hacker Recovery from positive reviews. They replied swiftly, handled my issue professionally, and walked me through every step. My valuables were returned within a week, giving me back my confidence. I heartily recommend their dependable, professional aid services. Contact Info: Website address: htt p:// iforcehackers. co m. Email: iforcehk @ consultant .co m WhatsApp: +1 240 803-3706

5 months, 2 weeks

HOW TO FIND A LEGITIMATE CRYPTO RECOVERY EXPERT; Contact iFORCE HACKER RECOVERY

by wsuttles6＠gmail.com

5 months, 2 weeks

Re: [PATCH] dma-fence: Fix sparse warnings due __rcu annotations

by Christian König

On 6/16/25 17:59, Tvrtko Ursulin wrote: > __rcu annotations on the return types from dma_fence_driver_name() and > dma_fence_timeline_name() cause sparse to complain because both the > constant signaled strings, and the strings return by the dma_fence_ops are > not __rcu annotated. > > For a simple fix it is easiest to cast them with __rcu added and undo the > smarts from the tracpoints side of things. There is no functional change > since the rest is left in place. Later we can consider changing the > dma_fence_ops return types too, and handle all the individual drivers > which define them. > > Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin(a)igalia.com> > Fixes: 506aa8b02a8d ("dma-fence: Add safe access helpers and document the rules") > Reported-by: kernel test robot <lkp(a)intel.com> > Closes: https://lore.kernel.org/oe-kbuild-all/202506162214.1eA69hLe-lkp@intel.com/ > Cc: Christian König <christian.koenig(a)amd.com> Sorry for the delayed reply, completed missed this one. Patch is reviewed and pushed to drm-misc-next. It eventually will be backported to stable kernels because of the fixes tag, but since this is not a functional bug I didn't added a CC:stable tag. Thanks, Christian. > --- > drivers/dma-buf/dma-fence.c | 8 ++++---- > include/trace/events/dma_fence.h | 35 +++++--------------------------- > 2 files changed, 9 insertions(+), 34 deletions(-) > > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c > index 3f78c56b58dc..da60d4e68b89 100644 > --- a/drivers/dma-buf/dma-fence.c > +++ b/drivers/dma-buf/dma-fence.c > @@ -1109,9 +1109,9 @@ const char __rcu *dma_fence_driver_name(struct dma_fence *fence) > "RCU protection is required for safe access to returned string"); > > if (!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) > - return fence->ops->get_driver_name(fence); > + return (const char __rcu *)fence->ops->get_driver_name(fence); > else > - return "detached-driver"; > + return (const char __rcu *)"detached-driver"; > } > EXPORT_SYMBOL(dma_fence_driver_name); > > @@ -1141,8 +1141,8 @@ const char __rcu *dma_fence_timeline_name(struct dma_fence *fence) > "RCU protection is required for safe access to returned string"); > > if (!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) > - return fence->ops->get_driver_name(fence); > + return (const char __rcu *)fence->ops->get_driver_name(fence); > else > - return "signaled-timeline"; > + return (const char __rcu *)"signaled-timeline"; > } > EXPORT_SYMBOL(dma_fence_timeline_name); > diff --git a/include/trace/events/dma_fence.h b/include/trace/events/dma_fence.h > index 4814a65b68dc..3abba45c0601 100644 > --- a/include/trace/events/dma_fence.h > +++ b/include/trace/events/dma_fence.h > @@ -9,37 +9,12 @@ > > struct dma_fence; > > -DECLARE_EVENT_CLASS(dma_fence, > - > - TP_PROTO(struct dma_fence *fence), > - > - TP_ARGS(fence), > - > - TP_STRUCT__entry( > - __string(driver, dma_fence_driver_name(fence)) > - __string(timeline, dma_fence_timeline_name(fence)) > - __field(unsigned int, context) > - __field(unsigned int, seqno) > - ), > - > - TP_fast_assign( > - __assign_str(driver); > - __assign_str(timeline); > - __entry->context = fence->context; > - __entry->seqno = fence->seqno; > - ), > - > - TP_printk("driver=%s timeline=%s context=%u seqno=%u", > - __get_str(driver), __get_str(timeline), __entry->context, > - __entry->seqno) > -); > - > /* > * Safe only for call sites which are guaranteed to not race with fence > * signaling,holding the fence->lock and having checked for not signaled, or the > * signaling path itself. > */ > -DECLARE_EVENT_CLASS(dma_fence_unsignaled, > +DECLARE_EVENT_CLASS(dma_fence, > > TP_PROTO(struct dma_fence *fence), > > @@ -64,14 +39,14 @@ DECLARE_EVENT_CLASS(dma_fence_unsignaled, > __entry->seqno) > ); > > -DEFINE_EVENT(dma_fence_unsignaled, dma_fence_emit, > +DEFINE_EVENT(dma_fence, dma_fence_emit, > > TP_PROTO(struct dma_fence *fence), > > TP_ARGS(fence) > ); > > -DEFINE_EVENT(dma_fence_unsignaled, dma_fence_init, > +DEFINE_EVENT(dma_fence, dma_fence_init, > > TP_PROTO(struct dma_fence *fence), > > @@ -85,14 +60,14 @@ DEFINE_EVENT(dma_fence, dma_fence_destroy, > TP_ARGS(fence) > ); > > -DEFINE_EVENT(dma_fence_unsignaled, dma_fence_enable_signal, > +DEFINE_EVENT(dma_fence, dma_fence_enable_signal, > > TP_PROTO(struct dma_fence *fence), > > TP_ARGS(fence) > ); > > -DEFINE_EVENT(dma_fence_unsignaled, dma_fence_signaled, > +DEFINE_EVENT(dma_fence, dma_fence_signaled, > > TP_PROTO(struct dma_fence *fence), >

5 months, 2 weeks

[RFC v2 05/11] block: add infra to handle dmabuf tokens

by asml.silence＠gmail.com

The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list.

5 months, 2 weeks

[RFC v2 04/11] block: introduce dma token backed bio type

by asml.silence＠gmail.com

The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list.

5 months, 2 weeks

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig February 2026