Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

12 participants
3625 discussions

[PATCH 0/7] dma-buf: heaps: Turn heaps into modules

by Maxime Ripard

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> --- Maxime Ripard (7): dma: contiguous: Turn heap registration logic around mm: cma: Export cma_alloc and cma_release mm: cma: Export cma_get_name mm: cma: Export dma_contiguous_default_area 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 | 21 +++++---------------- drivers/dma-buf/heaps/system_heap.c | 5 +++++ include/linux/dma-map-ops.h | 5 +++++ kernel/dma/contiguous.c | 27 +++++++++++++++++++++++++-- mm/cma.c | 3 +++ 7 files changed, 46 insertions(+), 20 deletions(-) --- base-commit: 499a718536dc0e1c1d1b6211847207d58acd9916 change-id: 20260225-dma-buf-heaps-as-modules-1034b3ec9f2a Best regards, -- Maxime Ripard <mripard(a)kernel.org>

7 months, 2 weeks

[PATCH v2 0/2] 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. --- v1->v2: patch1: - rebased on top of recent dma-mapping-fixes patch2: - fixed build errors on s390 by including mem_encrypt.h - converted system heap flag implementation to a separate heap Based on dma-mapping-fixes HEAD d5b5e8149af0f5efed58653cbebf1cb3258ce49a Jiri Pirko (2): dma-mapping: introduce DMA_ATTR_CC_DECRYPTED for pre-decrypted memory dma-buf: heaps: system: add system_cc_decrypted heap for explicitly decrypted memory drivers/dma-buf/heaps/system_heap.c | 103 ++++++++++++++++++++++++++-- include/linux/dma-heap.h | 1 + include/linux/dma-mapping.h | 6 ++ include/trace/events/dma.h | 3 +- include/uapi/linux/dma-heap.h | 3 +- kernel/dma/direct.h | 14 +++- 6 files changed, 119 insertions(+), 11 deletions(-) -- 2.51.1

7 months, 2 weeks

How to Recover Lost or Scammed Cryptocurrency, visit OPTIMISTIC HACKER GAIUS

by benjaminlucas0a＠gmail.com

OPTIMISTIC HACKER GAIUS is a professional crypto recovery service specializing in lost Bitcoin recovery, scammed USDT recovery, and digital asset tracing. The company uses advanced blockchain analysis and investigative techniques to track and recover stolen or inaccessible cryptocurrency. Known for clear communication and ethical practices, OPTIMISTIC HACKER GAIUS provides realistic assessments and reliable support for individuals and businesses affected by crypto-related losses. Mail-Box: support @ optimistichackargaius. c om WhatsApp: +44 737 674 0569 Website: optimistichackargaius. co m

7 months, 2 weeks

Re: [RFC PATCH v4 0/2] RDMA/rxe: Add dma-buf support

by Zhu Yanjun

在 2021/11/22 3:08, Shunsuke Mie 写道: > This patch series add a dma-buf support for rxe driver. > > A dma-buf based memory registering has beed introduced to use the memory > region that lack of associated page structures (e.g. device memory and CMA > managed memory) [1]. However, to use the dma-buf based memory, each rdma > device drivers require add some implementation. The rxe driver has not > support yet. > > [1] https://www.spinics.net/lists/linux-rdma/msg98592.html > > To enable to use the dma-buf memory in rxe rdma device, add some changes > and implementation in this patch series. > > This series consists of two patches. The first patch changes the IB core > to support for rdma drivers that has not dma device. The secound patch adds > the dma-buf support to rxe driver. > Hi, Shunsuke Mie I was revisiting your 2021 proposal around dma-buf integration with RDMA and the related discussions at the time. As you know, dma-buf usage in RDMA-related workflows has gained more traction recently, and we are seeing increasing interest in heterogeneous memory and cross-device buffer sharing. Given the changes in the ecosystem since then, I’m wondering whether you think the original direction might be worth reconsidering. Do you have any interest in continuing that line of work, or updating the design based on today’s context? If not, I’d still appreciate your perspective on what you see as the main blockers from the previous discussions, and whether you think the landscape has changed enough to justify another attempt. Depending on the direction, we may consider exploring dma-buf support in rxe or at the core level, but I’d prefer to first understand your view before moving forward. Zhu Yanjun > Related user space RDMA library changes are provided as a separate patch. > > v4: > * Fix warnings, unused variable and casting > v3: https://www.spinics.net/lists/linux-rdma/msg106776.html > * Rebase to the latest linux-rdma 'for-next' branch (5.15.0-rc6+) > * Fix to use dma-buf-map helpers > v2: https://www.spinics.net/lists/linux-rdma/msg105928.html > * Rebase to the latest linux-rdma 'for-next' branch (5.15.0-rc1+) > * Instead of using a dummy dma_device to attach dma-buf, just store > dma-buf to use software RDMA driver > * Use dma-buf vmap() interface > * Check to pass tests of rdma-core > v1: https://www.spinics.net/lists/linux-rdma/msg105376.html > * The initial patch set > * Use ib_device as dma_device. > * Use dma-buf dynamic attach interface > * Add dma-buf support to rxe device > > Shunsuke Mie (2): > RDMA/umem: Change for rdma devices has not dma device > RDMA/rxe: Add dma-buf support > > drivers/infiniband/core/umem_dmabuf.c | 20 ++++- > drivers/infiniband/sw/rxe/rxe_loc.h | 2 + > drivers/infiniband/sw/rxe/rxe_mr.c | 113 ++++++++++++++++++++++++++ > drivers/infiniband/sw/rxe/rxe_verbs.c | 34 ++++++++ > include/rdma/ib_umem.h | 1 + > 5 files changed, 166 insertions(+), 4 deletions(-) >

7 months, 2 weeks

Hire A Crypto Recovery Specialist; Recover Scammed Crypto With iForce Hacker Recovery

by aaronwycoff34＠gmail.com

Hello everyone, I wish to give my own review about iFORCE HACKER RECOVERY. I hope this message reaches the right audience. As an entrepreneur, I was eager to invest in cryptocurrency after learning about its potential to significantly increase my income. I came across someone online who promised exceptionally high returns, and because he seemed knowledgeable, I was easily convinced. After investing a substantial amount, I soon discovered that I was unable to withdraw my funds. It was all a scam. This left me in debt and caused severe damage to my business. Fortunately, I came across a pop-up about cryptocurrency recovery and cybersecurity experts. I reached out to iFORCE HACKER RECOVERY, a cybersecurity and cryptocurrency recovery company, and they successfully helped me recover my lost funds. I am incredibly grateful for their services and highly recommend them to anyone in need of cryptocurrency recovery assistance. Website; ht tps: //iforcehackers. co m/ Email; iforcehk @ consultant. c om Call/Text-whatsapp; +1 (240) 8033 (706)

7 months, 2 weeks

TOP 4 BEST GOOD CRYPTOCURRENCY RECOVERY SPECIALIST FOR LEGITIMATE CRYPTO RECOVERY IN 2026

by angelaasher62＠gmail.com

In 2026, cryptocurrency theft, scams, and accidental loss remain among the most common forms of digital financial harm. Phishing pages that clone Ledger or MetaMask interfaces, AI deepfake “support” calls, fake staking/yield platforms displaying fabricated profits, romance-to-crypto investment traps, wallet-draining malware, and unauthorized seed-phrase compromises continue to drain billions from users worldwide. When the funds disappear, the natural instinct is to search for “crypto recovery service” — only to discover that most results are secondary scams designed to exploit victims a second time. So should you hire a crypto recovery service? The expert consensus is clear: only if the service is genuinely legitimate, technically competent, transparent, and realistic. Hiring the wrong one almost always costs you more money and gives you zero chance of recovery. Hiring the right one significantly improves your realistic odds when funds are still traceable. When Hiring a Recovery Service Makes Sense Expert insight: Recovery is most viable in these scenarios: Funds recently sent to a scammer (within hours to a few days) The sooner you act, the less time scammers have to launder through mixers, cross-chain bridges, privacy protocols, or non-KYC off-ramps. Funds landed on a KYC/AML-compliant centralized exchange Regulated platforms (especially those operating in or serving U.S./EU jurisdictions) can freeze assets or cooperate with documented victims when presented with strong evidence. You have strong, complete evidence Multiple transaction IDs (TXIDs), sending/receiving addresses, scam messages/screenshots, deposit records, timelines, and communication logs dramatically increase traceability. Wallet access issue (not outright theft) Forgotten passwords, damaged hardware, or malware-compromised wallets can often be restored using secure, non-destructive professional methods. If your case matches one or more of these, hiring a reputable recovery service is often the smartest and most effective step you can take. When Hiring a Recovery Service Is Unlikely to Help Expert insight: Be realistic about low-success scenarios: Funds already laundered through multiple mixers/privacy coins and off-ramped to fiat Very small amounts (below most services’ minimum viable case threshold) No preserved evidence (missing TXIDs, screenshots, or communication logs) Loss occurred months or years ago with no traceable endpoints remaining In these situations, even the best legitimate service may conclude recovery is not feasible. Ethical experts will tell you this upfront — scammers will promise success anyway. How to Identify a Legitimate Recovery Service in 2026 The single most important decision is choosing the right provider. Here are the non-negotiable markers of legitimacy: Free, no-obligation initial case evaluation Never requests private keys, seed phrases, wallet access, or login credentials No large upfront fees before detailed feasibility review Uses only professional website + secure email (no Telegram/WhatsApp/DMs/forums as primary contact) Provides realistic success projections (no “100% guaranteed” or “instant recovery” claims) Delivers regular encrypted progress updates Focuses on blockchain forensics, exchange coordination, and documentation — not “magic hacks” Autopsy Mainnet Recovery (AMR) consistently meets every one of these criteria and is widely regarded as one of the most reputable and effective legitimate recovery services operating in 2026. Expert Insights from Autopsy Mainnet Recovery (AMR) Autopsy Mainnet Recovery (AMR), accessible only through their verified official platform at pucnonline.com, is frequently cited by scam victims and industry observers as a top-tier choice for several key reasons: Elite forensic capability — Advanced multi-chain tracing that maps funds even through complex laundering paths Endpoint intelligence — Strong focus on identifying when stolen assets reach compliant centralized exchanges Scam-specific expertise — Deep knowledge of 2026-era fraud vectors: phishing, fake yield platforms, deepfake impersonations, romance-to-crypto fraud Victim-first transparency — Free evaluations, detailed reports, no sensitive data requests, regular updates, realistic expectations Secure & ethical process — Official channels only ( https://autospyrec.site and info(a)autopsymainnetsolutions.com ), strict confidentiality, post-recovery security guidance Autopsy Mainnet Recovery (AMR)’s experts emphasize that speed + evidence + legitimate professional help is the formula that produces the highest realistic success rates. Final Expert Recommendation Should you hire a crypto recovery service? Yes — if you choose a legitimate one and act quickly. Hiring a reputable provider like Autopsy Mainnet Recovery (AMR) significantly improves your chances when funds remain traceable, while also protecting you from secondary scams that would only deepen your losses. If you’ve lost crypto assets: Preserve every piece of evidence immediately Secure remaining holdings in a new hardware wallet File official reports (IC3.gov, ReportFraud.ftc.gov, etc.) Contact only verified official channels for a free evaluation Visit https://www.autopsymainnetsolutions.com or email info(a)autopsymainnetsolutions.com today for a confidential consultation. Never pay upfront fees without a detailed review. Never share sensitive wallet information. Never trust unsolicited offers. Recovery is difficult and never guaranteed, but the right legitimate service gives you the strongest realistic opportunity to reclaim what was stolen in today’s challenging environment. Stay vigilant, verify everything, and protect your digital future.

7 months, 2 weeks

[PATCH rdma-next v3 0/3] RDMA: Add support for exporting dma-buf file descriptors

by Edward Srouji

This patch series introduces dma-buf export support for RDMA/InfiniBand devices, enabling userspace applications to export RDMA PCI-backed memory regions (such as device memory or mlx5 UAR pages) as dma-buf file descriptors. This allows PCI device memory to be shared with other kernel subsystems (e.g., graphics or media) or between userspace processes, via the standard dma-buf interface, avoiding unnecessary copies and enabling efficient peer-to-peer (P2P) DMA transfers. See [1] for background on dma-buf. As part of this series, we introduce a new uverbs object of type FD for dma-buf export, along with the corresponding APIs for allocation and teardown. This object encapsulates all attributes required to export a dma-buf. The implementation enforces P2P-only mappings and properly manages resource lifecycle, including: - Cleanup during driver removal or RDMA context destruction. - Revocation via dma_buf_move_notify() when the underlying mmap entries are removed. - Refactors common cleanup logic for reuse across FD uobject types. The infrastructure is generic within uverbs, allowing individual drivers to easily integrate and supply their vendor-specific implementation. The mlx5 driver is the first consumer of this new API, providing: - Initialization of PCI peer-to-peer DMA support. - mlx5-specific implementations of the mmap_get_pfns and pgoff_to_mmap_entry device operations required for dma-buf export. [1] https://docs.kernel.org/driver-api/dma-buf.html Signed-off-by: Yishai Hadas <yishaih(a)nvidia.com> Signed-off-by: Edward Srouji <edwards(a)nvidia.com> --- Changes in v3: - Wait for importers to complete their unmap() calls after dma_buf_move_notify(), ensuring all mappings are properly cleaned up before revocation - Add unpin callback to pair with pin (both are required by dma-buf ops) - Link to v2: https://lore.kernel.org/r/20260121-dmabuf-export-v2-0-6381183bcc3d@nvidia.c… Changes in v2: - Split the FD uobject refactoring into a separate patch ("RDMA: Add support for exporting dma-buf file descriptors") - Remove redundant revoked check from attach callback. It is checked during map - Add pin callback that returns -EOPNOTSUPP to explicitly refuse pinned importers - Wait for pending fences after dma_buf_move_notify() using dma_resv_wait_timeout() to ensure hardware has completed all in-flight operations before proceeding - Link to v1: https://lore.kernel.org/r/20260108-dmabuf-export-v1-0-6d47d46580d3@nvidia.c… --- Yishai Hadas (3): RDMA/uverbs: Support external FD uobjects RDMA/uverbs: Add DMABUF object type and operations RDMA/mlx5: Implement DMABUF export ops drivers/infiniband/core/Makefile | 1 + drivers/infiniband/core/device.c | 2 + drivers/infiniband/core/ib_core_uverbs.c | 24 +++ drivers/infiniband/core/rdma_core.c | 63 ++++--- drivers/infiniband/core/rdma_core.h | 1 + drivers/infiniband/core/uverbs.h | 21 +++ drivers/infiniband/core/uverbs_std_types_dmabuf.c | 200 ++++++++++++++++++++++ drivers/infiniband/core/uverbs_uapi.c | 1 + drivers/infiniband/hw/mlx5/main.c | 72 ++++++++ include/rdma/ib_verbs.h | 9 + include/rdma/uverbs_types.h | 1 + include/uapi/rdma/ib_user_ioctl_cmds.h | 10 ++ 12 files changed, 379 insertions(+), 26 deletions(-) --- base-commit: 325e3b5431ddd27c5f93156b36838a351e3b2f72 change-id: 20260108-dmabuf-export-0d598058dd1e Best regards, -- Edward Srouji <edwards(a)nvidia.com>

7 months, 2 weeks

How to Recover Lost or Scammed Cryptocurrency, visit OPTIMISTIC HACKER GAIUS

by benjaminlucas0a＠gmail.com

7 months, 3 weeks

[PATCH 2/8] dma-buf: detach fence ops on signal v2

by Christian König

When neither a release nor a wait backend ops is specified it is possible to let the dma_fence live on independently of the module who issued it. This makes it possible to unload drivers and only wait for all their fences to signal. v2: fix typo in comment Signed-off-by: Christian König <christian.koenig(a)amd.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin(a)igalia.com> Reviewed-by: Philipp Stanner <phasta(a)kernel.org> Reviewed-by: Boris Brezillon <boris.brezillon(a)collabora.com> --- drivers/dma-buf/dma-fence.c | 16 ++++++++++++---- include/linux/dma-fence.h | 4 ++-- 2 files changed, 14 insertions(+), 6 deletions(-) diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c index d3c4e23bf297..ae77f900c267 100644 --- a/drivers/dma-buf/dma-fence.c +++ b/drivers/dma-buf/dma-fence.c @@ -371,6 +371,14 @@ void dma_fence_signal_timestamp_locked(struct dma_fence *fence, &fence->flags))) return; + /* + * When neither a release nor a wait operation is specified set the ops + * pointer to NULL to allow the fence structure to become independent + * from who originally issued it. + */ + if (!fence->ops->release && !fence->ops->wait) + RCU_INIT_POINTER(fence->ops, NULL); + /* Stash the cb_list before replacing it with the timestamp */ list_replace(&fence->cb_list, &cb_list); @@ -537,7 +545,7 @@ dma_fence_wait_timeout(struct dma_fence *fence, bool intr, signed long timeout) rcu_read_lock(); ops = rcu_dereference(fence->ops); trace_dma_fence_wait_start(fence); - if (ops->wait) { + if (ops && ops->wait) { /* * Implementing the wait ops is deprecated and not supported for * issuers of fences who need their lifetime to be independent @@ -603,7 +611,7 @@ void dma_fence_release(struct kref *kref) } ops = rcu_dereference(fence->ops); - if (ops->release) + if (ops && ops->release) ops->release(fence); else dma_fence_free(fence); @@ -639,7 +647,7 @@ static bool __dma_fence_enable_signaling(struct dma_fence *fence) rcu_read_lock(); ops = rcu_dereference(fence->ops); - if (!was_set && ops->enable_signaling) { + if (!was_set && ops && ops->enable_signaling) { trace_dma_fence_enable_signal(fence); if (!ops->enable_signaling(fence)) { @@ -1025,7 +1033,7 @@ void dma_fence_set_deadline(struct dma_fence *fence, ktime_t deadline) rcu_read_lock(); ops = rcu_dereference(fence->ops); - if (ops->set_deadline && !dma_fence_is_signaled(fence)) + if (ops && ops->set_deadline && !dma_fence_is_signaled(fence)) ops->set_deadline(fence, deadline); rcu_read_unlock(); } diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h index 9d8a4ebe8bf7..80db7ede91de 100644 --- a/include/linux/dma-fence.h +++ b/include/linux/dma-fence.h @@ -472,7 +472,7 @@ dma_fence_is_signaled_locked(struct dma_fence *fence) rcu_read_lock(); ops = rcu_dereference(fence->ops); - if (ops->signaled && ops->signaled(fence)) { + if (ops && ops->signaled && ops->signaled(fence)) { rcu_read_unlock(); dma_fence_signal_locked(fence); return true; @@ -508,7 +508,7 @@ dma_fence_is_signaled(struct dma_fence *fence) rcu_read_lock(); ops = rcu_dereference(fence->ops); - if (ops->signaled && ops->signaled(fence)) { + if (ops && ops->signaled && ops->signaled(fence)) { rcu_read_unlock(); dma_fence_signal(fence); return true; -- 2.43.0

7 months, 3 weeks

[PATCH 1/8] dma-buf: protected fence ops by RCU v7

by Christian König

The fence ops of a dma_fence currently need to life as long as the dma_fence is alive. This means that the module which originally issued a dma_fence can't unload unless all fences are freed up. As first step to solve this issue protect the fence ops by RCU. While it is counter intuitive to protect a constant function pointer table by RCU it allows modules to wait for an RCU grace period before they unload, to make sure that nobody is executing their functions any more. This patch has not much functional change, but only adds the RCU handling for the static checker to test. v2: make one the now duplicated lockdep warnings a comment instead. v3: Add more documentation to ->wait and ->release callback. v4: fix typo in documentation v5: rebased on drm-tip v6: improve code comments v7: improve commit message and code comments Signed-off-by: Christian König <christian.koenig(a)amd.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin(a)igalia.com> Reviewed-by: Boris Brezillon <boris.brezillon(a)collabora.com> --- drivers/dma-buf/dma-fence.c | 71 +++++++++++++++++++++++++------------ include/linux/dma-fence.h | 29 +++++++++++++-- 2 files changed, 75 insertions(+), 25 deletions(-) diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c index e05beae6e407..d3c4e23bf297 100644 --- a/drivers/dma-buf/dma-fence.c +++ b/drivers/dma-buf/dma-fence.c @@ -522,6 +522,7 @@ EXPORT_SYMBOL(dma_fence_signal); signed long dma_fence_wait_timeout(struct dma_fence *fence, bool intr, signed long timeout) { + const struct dma_fence_ops *ops; signed long ret; if (WARN_ON(timeout < 0)) @@ -533,15 +534,22 @@ dma_fence_wait_timeout(struct dma_fence *fence, bool intr, signed long timeout) dma_fence_enable_sw_signaling(fence); - if (trace_dma_fence_wait_start_enabled()) { - rcu_read_lock(); - trace_dma_fence_wait_start(fence); + rcu_read_lock(); + ops = rcu_dereference(fence->ops); + trace_dma_fence_wait_start(fence); + if (ops->wait) { + /* + * Implementing the wait ops is deprecated and not supported for + * issuers of fences who need their lifetime to be independent + * of their module after they signal, so it is ok to use the + * ops outside the RCU protected section. + */ + rcu_read_unlock(); + ret = ops->wait(fence, intr, timeout); + } else { rcu_read_unlock(); - } - if (fence->ops->wait) - ret = fence->ops->wait(fence, intr, timeout); - else ret = dma_fence_default_wait(fence, intr, timeout); + } if (trace_dma_fence_wait_end_enabled()) { rcu_read_lock(); trace_dma_fence_wait_end(fence); @@ -562,6 +570,7 @@ void dma_fence_release(struct kref *kref) { struct dma_fence *fence = container_of(kref, struct dma_fence, refcount); + const struct dma_fence_ops *ops; rcu_read_lock(); trace_dma_fence_destroy(fence); @@ -593,12 +602,12 @@ void dma_fence_release(struct kref *kref) spin_unlock_irqrestore(fence->lock, flags); } - rcu_read_unlock(); - - if (fence->ops->release) - fence->ops->release(fence); + ops = rcu_dereference(fence->ops); + if (ops->release) + ops->release(fence); else dma_fence_free(fence); + rcu_read_unlock(); } EXPORT_SYMBOL(dma_fence_release); @@ -617,6 +626,7 @@ EXPORT_SYMBOL(dma_fence_free); static bool __dma_fence_enable_signaling(struct dma_fence *fence) { + const struct dma_fence_ops *ops; bool was_set; lockdep_assert_held(fence->lock); @@ -627,14 +637,18 @@ static bool __dma_fence_enable_signaling(struct dma_fence *fence) if (dma_fence_test_signaled_flag(fence)) return false; - if (!was_set && fence->ops->enable_signaling) { + rcu_read_lock(); + ops = rcu_dereference(fence->ops); + if (!was_set && ops->enable_signaling) { trace_dma_fence_enable_signal(fence); - if (!fence->ops->enable_signaling(fence)) { + if (!ops->enable_signaling(fence)) { + rcu_read_unlock(); dma_fence_signal_locked(fence); return false; } } + rcu_read_unlock(); return true; } @@ -1007,8 +1021,13 @@ EXPORT_SYMBOL(dma_fence_wait_any_timeout); */ void dma_fence_set_deadline(struct dma_fence *fence, ktime_t deadline) { - if (fence->ops->set_deadline && !dma_fence_is_signaled(fence)) - fence->ops->set_deadline(fence, deadline); + const struct dma_fence_ops *ops; + + rcu_read_lock(); + ops = rcu_dereference(fence->ops); + if (ops->set_deadline && !dma_fence_is_signaled(fence)) + ops->set_deadline(fence, deadline); + rcu_read_unlock(); } EXPORT_SYMBOL(dma_fence_set_deadline); @@ -1049,7 +1068,13 @@ __dma_fence_init(struct dma_fence *fence, const struct dma_fence_ops *ops, BUG_ON(!ops || !ops->get_driver_name || !ops->get_timeline_name); kref_init(&fence->refcount); - fence->ops = ops; + /* + * While it is counter intuitive to protect a constant function pointer + * table by RCU it allows modules to wait for an RCU grace period + * before they unload, to make sure that nobody is executing their + * functions any more. + */ + RCU_INIT_POINTER(fence->ops, ops); INIT_LIST_HEAD(&fence->cb_list); fence->lock = lock; fence->context = context; @@ -1129,11 +1154,12 @@ EXPORT_SYMBOL(dma_fence_init64); */ const char __rcu *dma_fence_driver_name(struct dma_fence *fence) { - RCU_LOCKDEP_WARN(!rcu_read_lock_held(), - "RCU protection is required for safe access to returned string"); + const struct dma_fence_ops *ops; + /* RCU protection is required for safe access to returned string */ + ops = rcu_dereference(fence->ops); if (!dma_fence_test_signaled_flag(fence)) - return (const char __rcu *)fence->ops->get_driver_name(fence); + return (const char __rcu *)ops->get_driver_name(fence); else return (const char __rcu *)"detached-driver"; } @@ -1161,11 +1187,12 @@ EXPORT_SYMBOL(dma_fence_driver_name); */ const char __rcu *dma_fence_timeline_name(struct dma_fence *fence) { - RCU_LOCKDEP_WARN(!rcu_read_lock_held(), - "RCU protection is required for safe access to returned string"); + const struct dma_fence_ops *ops; + /* RCU protection is required for safe access to returned string */ + ops = rcu_dereference(fence->ops); if (!dma_fence_test_signaled_flag(fence)) - return (const char __rcu *)fence->ops->get_driver_name(fence); + return (const char __rcu *)ops->get_driver_name(fence); else return (const char __rcu *)"signaled-timeline"; } diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h index 9c4d25289239..9d8a4ebe8bf7 100644 --- a/include/linux/dma-fence.h +++ b/include/linux/dma-fence.h @@ -67,7 +67,7 @@ struct seq_file; */ struct dma_fence { spinlock_t *lock; - const struct dma_fence_ops *ops; + const struct dma_fence_ops __rcu *ops; /* * We clear the callback list on kref_put so that by the time we * release the fence it is unused. No one should be adding to the @@ -220,6 +220,10 @@ struct dma_fence_ops { * timed out. Can also return other error values on custom implementations, * which should be treated as if the fence is signaled. For example a hardware * lockup could be reported like that. + * + * Implementing this callback prevents the fence from detaching after + * signaling and so it is necessary for the module providing the + * dma_fence_ops to stay loaded as long as the dma_fence exists. */ signed long (*wait)(struct dma_fence *fence, bool intr, signed long timeout); @@ -231,6 +235,13 @@ struct dma_fence_ops { * Can be called from irq context. This callback is optional. If it is * NULL, then dma_fence_free() is instead called as the default * implementation. + * + * Implementing this callback prevents the fence from detaching after + * signaling and so it is necessary for the module providing the + * dma_fence_ops to stay loaded as long as the dma_fence exists. + * + * If the callback is implemented the memory backing the dma_fence + * object must be freed RCU safe. */ void (*release)(struct dma_fence *fence); @@ -454,13 +465,19 @@ dma_fence_test_signaled_flag(struct dma_fence *fence) static inline bool dma_fence_is_signaled_locked(struct dma_fence *fence) { + const struct dma_fence_ops *ops; + if (dma_fence_test_signaled_flag(fence)) return true; - if (fence->ops->signaled && fence->ops->signaled(fence)) { + rcu_read_lock(); + ops = rcu_dereference(fence->ops); + if (ops->signaled && ops->signaled(fence)) { + rcu_read_unlock(); dma_fence_signal_locked(fence); return true; } + rcu_read_unlock(); return false; } @@ -484,13 +501,19 @@ dma_fence_is_signaled_locked(struct dma_fence *fence) static inline bool dma_fence_is_signaled(struct dma_fence *fence) { + const struct dma_fence_ops *ops; + if (dma_fence_test_signaled_flag(fence)) return true; - if (fence->ops->signaled && fence->ops->signaled(fence)) { + rcu_read_lock(); + ops = rcu_dereference(fence->ops); + if (ops->signaled && ops->signaled(fence)) { + rcu_read_unlock(); dma_fence_signal(fence); return true; } + rcu_read_unlock(); return false; } -- 2.43.0

7 months, 3 weeks

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig