Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

51 participants
3581 discussions

[PATCH 3/8] dma-buf: abstract fence locking v2

by Christian König

Add dma_fence_lock_irqsafe() and dma_fence_unlock_irqrestore() wrappers and mechanically apply them everywhere. Just a pre-requisite cleanup for a follow up patch. v2: add some missing i915 bits, add abstraction for lockdep assertion as well v3: one more suggestion by Tvrtko Signed-off-by: Christian König <christian.koenig(a)amd.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin(a)igalia.com> --- drivers/dma-buf/dma-fence.c | 48 ++++++++++----------- drivers/dma-buf/st-dma-fence.c | 6 ++- drivers/dma-buf/sw_sync.c | 14 +++--- drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 2 +- drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 2 +- drivers/gpu/drm/i915/i915_active.c | 19 ++++---- drivers/gpu/drm/nouveau/nouveau_drm.c | 5 ++- drivers/gpu/drm/scheduler/sched_fence.c | 6 +-- drivers/gpu/drm/xe/xe_sched_job.c | 4 +- include/linux/dma-fence.h | 38 ++++++++++++++++ 12 files changed, 96 insertions(+), 56 deletions(-) diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c index ae77f900c267..bd4ec7e26dae 100644 --- a/drivers/dma-buf/dma-fence.c +++ b/drivers/dma-buf/dma-fence.c @@ -365,7 +365,7 @@ void dma_fence_signal_timestamp_locked(struct dma_fence *fence, struct dma_fence_cb *cur, *tmp; struct list_head cb_list; - lockdep_assert_held(fence->lock); + dma_fence_assert_held(fence); if (unlikely(test_and_set_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))) @@ -412,9 +412,9 @@ void dma_fence_signal_timestamp(struct dma_fence *fence, ktime_t timestamp) if (WARN_ON(!fence)) return; - spin_lock_irqsave(fence->lock, flags); + dma_fence_lock_irqsave(fence, flags); dma_fence_signal_timestamp_locked(fence, timestamp); - spin_unlock_irqrestore(fence->lock, flags); + dma_fence_unlock_irqrestore(fence, flags); } EXPORT_SYMBOL(dma_fence_signal_timestamp); @@ -473,9 +473,9 @@ bool dma_fence_check_and_signal(struct dma_fence *fence) unsigned long flags; bool ret; - spin_lock_irqsave(fence->lock, flags); + dma_fence_lock_irqsave(fence, flags); ret = dma_fence_check_and_signal_locked(fence); - spin_unlock_irqrestore(fence->lock, flags); + dma_fence_unlock_irqrestore(fence, flags); return ret; } @@ -501,9 +501,9 @@ void dma_fence_signal(struct dma_fence *fence) tmp = dma_fence_begin_signalling(); - spin_lock_irqsave(fence->lock, flags); + dma_fence_lock_irqsave(fence, flags); dma_fence_signal_timestamp_locked(fence, ktime_get()); - spin_unlock_irqrestore(fence->lock, flags); + dma_fence_unlock_irqrestore(fence, flags); dma_fence_end_signalling(tmp); } @@ -604,10 +604,10 @@ void dma_fence_release(struct kref *kref) * don't leave chains dangling. We set the error flag first * so that the callbacks know this signal is due to an error. */ - spin_lock_irqsave(fence->lock, flags); + dma_fence_lock_irqsave(fence, flags); fence->error = -EDEADLK; dma_fence_signal_locked(fence); - spin_unlock_irqrestore(fence->lock, flags); + dma_fence_unlock_irqrestore(fence, flags); } ops = rcu_dereference(fence->ops); @@ -637,7 +637,7 @@ static bool __dma_fence_enable_signaling(struct dma_fence *fence) const struct dma_fence_ops *ops; bool was_set; - lockdep_assert_held(fence->lock); + dma_fence_assert_held(fence); was_set = test_and_set_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, &fence->flags); @@ -673,9 +673,9 @@ void dma_fence_enable_sw_signaling(struct dma_fence *fence) { unsigned long flags; - spin_lock_irqsave(fence->lock, flags); + dma_fence_lock_irqsave(fence, flags); __dma_fence_enable_signaling(fence); - spin_unlock_irqrestore(fence->lock, flags); + dma_fence_unlock_irqrestore(fence, flags); } EXPORT_SYMBOL(dma_fence_enable_sw_signaling); @@ -715,8 +715,7 @@ int dma_fence_add_callback(struct dma_fence *fence, struct dma_fence_cb *cb, return -ENOENT; } - spin_lock_irqsave(fence->lock, flags); - + dma_fence_lock_irqsave(fence, flags); if (__dma_fence_enable_signaling(fence)) { cb->func = func; list_add_tail(&cb->node, &fence->cb_list); @@ -724,8 +723,7 @@ int dma_fence_add_callback(struct dma_fence *fence, struct dma_fence_cb *cb, INIT_LIST_HEAD(&cb->node); ret = -ENOENT; } - - spin_unlock_irqrestore(fence->lock, flags); + dma_fence_unlock_irqrestore(fence, flags); return ret; } @@ -748,9 +746,9 @@ int dma_fence_get_status(struct dma_fence *fence) unsigned long flags; int status; - spin_lock_irqsave(fence->lock, flags); + dma_fence_lock_irqsave(fence, flags); status = dma_fence_get_status_locked(fence); - spin_unlock_irqrestore(fence->lock, flags); + dma_fence_unlock_irqrestore(fence, flags); return status; } @@ -780,13 +778,11 @@ dma_fence_remove_callback(struct dma_fence *fence, struct dma_fence_cb *cb) unsigned long flags; bool ret; - spin_lock_irqsave(fence->lock, flags); - + dma_fence_lock_irqsave(fence, flags); ret = !list_empty(&cb->node); if (ret) list_del_init(&cb->node); - - spin_unlock_irqrestore(fence->lock, flags); + dma_fence_unlock_irqrestore(fence, flags); return ret; } @@ -825,7 +821,7 @@ dma_fence_default_wait(struct dma_fence *fence, bool intr, signed long timeout) unsigned long flags; signed long ret = timeout ? timeout : 1; - spin_lock_irqsave(fence->lock, flags); + dma_fence_lock_irqsave(fence, flags); if (dma_fence_test_signaled_flag(fence)) goto out; @@ -849,11 +845,11 @@ dma_fence_default_wait(struct dma_fence *fence, bool intr, signed long timeout) __set_current_state(TASK_INTERRUPTIBLE); else __set_current_state(TASK_UNINTERRUPTIBLE); - spin_unlock_irqrestore(fence->lock, flags); + dma_fence_unlock_irqrestore(fence, flags); ret = schedule_timeout(ret); - spin_lock_irqsave(fence->lock, flags); + dma_fence_lock_irqsave(fence, flags); if (ret > 0 && intr && signal_pending(current)) ret = -ERESTARTSYS; } @@ -863,7 +859,7 @@ dma_fence_default_wait(struct dma_fence *fence, bool intr, signed long timeout) __set_current_state(TASK_RUNNING); out: - spin_unlock_irqrestore(fence->lock, flags); + dma_fence_unlock_irqrestore(fence, flags); return ret; } EXPORT_SYMBOL(dma_fence_default_wait); diff --git a/drivers/dma-buf/st-dma-fence.c b/drivers/dma-buf/st-dma-fence.c index 73ed6fd48a13..5d0d9abc6e21 100644 --- a/drivers/dma-buf/st-dma-fence.c +++ b/drivers/dma-buf/st-dma-fence.c @@ -410,8 +410,10 @@ struct race_thread { static void __wait_for_callbacks(struct dma_fence *f) { - spin_lock_irq(f->lock); - spin_unlock_irq(f->lock); + unsigned long flags; + + dma_fence_lock_irqsave(f, flags); + dma_fence_unlock_irqrestore(f, flags); } static int thread_signal_callback(void *arg) diff --git a/drivers/dma-buf/sw_sync.c b/drivers/dma-buf/sw_sync.c index 6f09d13be6b6..4c81a37dd682 100644 --- a/drivers/dma-buf/sw_sync.c +++ b/drivers/dma-buf/sw_sync.c @@ -156,12 +156,12 @@ static void timeline_fence_release(struct dma_fence *fence) struct sync_timeline *parent = dma_fence_parent(fence); unsigned long flags; - spin_lock_irqsave(fence->lock, flags); + dma_fence_lock_irqsave(fence, flags); if (!list_empty(&pt->link)) { list_del(&pt->link); rb_erase(&pt->node, &parent->pt_tree); } - spin_unlock_irqrestore(fence->lock, flags); + dma_fence_unlock_irqrestore(fence, flags); sync_timeline_put(parent); dma_fence_free(fence); @@ -179,7 +179,7 @@ static void timeline_fence_set_deadline(struct dma_fence *fence, ktime_t deadlin struct sync_pt *pt = dma_fence_to_sync_pt(fence); unsigned long flags; - spin_lock_irqsave(fence->lock, flags); + dma_fence_lock_irqsave(fence, flags); if (test_bit(SW_SYNC_HAS_DEADLINE_BIT, &fence->flags)) { if (ktime_before(deadline, pt->deadline)) pt->deadline = deadline; @@ -187,7 +187,7 @@ static void timeline_fence_set_deadline(struct dma_fence *fence, ktime_t deadlin pt->deadline = deadline; __set_bit(SW_SYNC_HAS_DEADLINE_BIT, &fence->flags); } - spin_unlock_irqrestore(fence->lock, flags); + dma_fence_unlock_irqrestore(fence, flags); } static const struct dma_fence_ops timeline_fence_ops = { @@ -431,13 +431,13 @@ static int sw_sync_ioctl_get_deadline(struct sync_timeline *obj, unsigned long a goto put_fence; } - spin_lock_irqsave(fence->lock, flags); + dma_fence_lock_irqsave(fence, flags); if (!test_bit(SW_SYNC_HAS_DEADLINE_BIT, &fence->flags)) { ret = -ENOENT; goto unlock; } data.deadline_ns = ktime_to_ns(pt->deadline); - spin_unlock_irqrestore(fence->lock, flags); + dma_fence_unlock_irqrestore(fence, flags); dma_fence_put(fence); @@ -450,7 +450,7 @@ static int sw_sync_ioctl_get_deadline(struct sync_timeline *obj, unsigned long a return 0; unlock: - spin_unlock_irqrestore(fence->lock, flags); + dma_fence_unlock_irqrestore(fence, flags); put_fence: dma_fence_put(fence); diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c index b82357c65723..1404e1fe62a4 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c @@ -479,10 +479,10 @@ bool amdgpu_ring_soft_recovery(struct amdgpu_ring *ring, unsigned int vmid, if (amdgpu_sriov_vf(ring->adev) || !ring->funcs->soft_recovery || !fence) return false; - spin_lock_irqsave(fence->lock, flags); + dma_fence_lock_irqsave(fence, flags); if (!dma_fence_is_signaled_locked(fence)) dma_fence_set_error(fence, -ENODATA); - spin_unlock_irqrestore(fence->lock, flags); + dma_fence_unlock_irqrestore(fence, flags); while (!dma_fence_is_signaled(fence) && ktime_to_ns(ktime_sub(deadline, ktime_get())) > 0) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c index 6a2ea200d90c..4761e7486811 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c @@ -2802,8 +2802,8 @@ void amdgpu_vm_fini(struct amdgpu_device *adev, struct amdgpu_vm *vm) dma_fence_put(vm->last_unlocked); dma_fence_wait(vm->last_tlb_flush, false); /* Make sure that all fence callbacks have completed */ - spin_lock_irqsave(vm->last_tlb_flush->lock, flags); - spin_unlock_irqrestore(vm->last_tlb_flush->lock, flags); + dma_fence_lock_irqsave(vm->last_tlb_flush, flags); + dma_fence_unlock_irqrestore(vm->last_tlb_flush, flags); dma_fence_put(vm->last_tlb_flush); list_for_each_entry_safe(mapping, tmp, &vm->freed, list) { diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h index 139642eacdd0..d5c41e24fb51 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h @@ -638,7 +638,7 @@ static inline uint64_t amdgpu_vm_tlb_seq(struct amdgpu_vm *vm) * sure that the dma_fence structure isn't freed up. */ rcu_read_lock(); - lock = vm->last_tlb_flush->lock; + lock = dma_fence_spinlock(vm->last_tlb_flush); rcu_read_unlock(); spin_lock_irqsave(lock, flags); diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c index bf6117d5fc57..78ea2d9ccedf 100644 --- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c +++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c @@ -148,7 +148,7 @@ __dma_fence_signal__notify(struct dma_fence *fence, { struct dma_fence_cb *cur, *tmp; - lockdep_assert_held(fence->lock); + dma_fence_assert_held(fence); list_for_each_entry_safe(cur, tmp, list, node) { INIT_LIST_HEAD(&cur->node); diff --git a/drivers/gpu/drm/i915/i915_active.c b/drivers/gpu/drm/i915/i915_active.c index 6b0c1162505a..9d41e052ab65 100644 --- a/drivers/gpu/drm/i915/i915_active.c +++ b/drivers/gpu/drm/i915/i915_active.c @@ -1045,9 +1045,10 @@ __i915_active_fence_set(struct i915_active_fence *active, * nesting rules for the fence->lock; the inner lock is always the * older lock. */ - spin_lock_irqsave(fence->lock, flags); + dma_fence_lock_irqsave(fence, flags); if (prev) - spin_lock_nested(prev->lock, SINGLE_DEPTH_NESTING); + spin_lock_nested(dma_fence_spinlock(prev), + SINGLE_DEPTH_NESTING); /* * A does the cmpxchg first, and so it sees C or NULL, as before, or @@ -1061,17 +1062,18 @@ __i915_active_fence_set(struct i915_active_fence *active, */ while (cmpxchg(__active_fence_slot(active), prev, fence) != prev) { if (prev) { - spin_unlock(prev->lock); + spin_unlock(dma_fence_spinlock(prev)); dma_fence_put(prev); } - spin_unlock_irqrestore(fence->lock, flags); + dma_fence_unlock_irqrestore(fence, flags); prev = i915_active_fence_get(active); GEM_BUG_ON(prev == fence); - spin_lock_irqsave(fence->lock, flags); + dma_fence_lock_irqsave(fence, flags); if (prev) - spin_lock_nested(prev->lock, SINGLE_DEPTH_NESTING); + spin_lock_nested(dma_fence_spinlock(prev), + SINGLE_DEPTH_NESTING); } /* @@ -1088,10 +1090,11 @@ __i915_active_fence_set(struct i915_active_fence *active, */ if (prev) { __list_del_entry(&active->cb.node); - spin_unlock(prev->lock); /* serialise with prev->cb_list */ + /* serialise with prev->cb_list */ + spin_unlock(dma_fence_spinlock(prev)); } list_add_tail(&active->cb.node, &fence->cb_list); - spin_unlock_irqrestore(fence->lock, flags); + dma_fence_unlock_irqrestore(fence, flags); return prev; } diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c index f2e04a048ac2..e6805b8b9ffa 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drm.c +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c @@ -156,12 +156,13 @@ nouveau_name(struct drm_device *dev) static inline bool nouveau_cli_work_ready(struct dma_fence *fence) { + unsigned long flags; bool ret = true; - spin_lock_irq(fence->lock); + dma_fence_lock_irqsave(fence, flags); if (!dma_fence_is_signaled_locked(fence)) ret = false; - spin_unlock_irq(fence->lock); + dma_fence_unlock_irqrestore(fence, flags); if (ret == true) dma_fence_put(fence); diff --git a/drivers/gpu/drm/scheduler/sched_fence.c b/drivers/gpu/drm/scheduler/sched_fence.c index 9391d6f0dc01..724d77694246 100644 --- a/drivers/gpu/drm/scheduler/sched_fence.c +++ b/drivers/gpu/drm/scheduler/sched_fence.c @@ -156,19 +156,19 @@ static void drm_sched_fence_set_deadline_finished(struct dma_fence *f, struct dma_fence *parent; unsigned long flags; - spin_lock_irqsave(&fence->lock, flags); + dma_fence_lock_irqsave(f, flags); /* If we already have an earlier deadline, keep it: */ if (test_bit(DRM_SCHED_FENCE_FLAG_HAS_DEADLINE_BIT, &f->flags) && ktime_before(fence->deadline, deadline)) { - spin_unlock_irqrestore(&fence->lock, flags); + dma_fence_unlock_irqrestore(f, flags); return; } fence->deadline = deadline; set_bit(DRM_SCHED_FENCE_FLAG_HAS_DEADLINE_BIT, &f->flags); - spin_unlock_irqrestore(&fence->lock, flags); + dma_fence_unlock_irqrestore(f, flags); /* * smp_load_aquire() to ensure that if we are racing another diff --git a/drivers/gpu/drm/xe/xe_sched_job.c b/drivers/gpu/drm/xe/xe_sched_job.c index 3927666fe556..ae5b38b2a884 100644 --- a/drivers/gpu/drm/xe/xe_sched_job.c +++ b/drivers/gpu/drm/xe/xe_sched_job.c @@ -190,11 +190,11 @@ static bool xe_fence_set_error(struct dma_fence *fence, int error) unsigned long irq_flags; bool signaled; - spin_lock_irqsave(fence->lock, irq_flags); + dma_fence_lock_irqsave(fence, irq_flags); signaled = test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags); if (!signaled) dma_fence_set_error(fence, error); - spin_unlock_irqrestore(fence->lock, irq_flags); + dma_fence_unlock_irqrestore(fence, irq_flags); return signaled; } diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h index 80db7ede91de..086324af96c9 100644 --- a/include/linux/dma-fence.h +++ b/include/linux/dma-fence.h @@ -377,6 +377,44 @@ dma_fence_get_rcu_safe(struct dma_fence __rcu **fencep) } while (1); } +/** + * dma_fence_spinlock - return pointer to the spinlock protecting the fence + * @fence: the fence to get the lock from + * + * Return the pointer to the extern lock. + */ +static inline spinlock_t *dma_fence_spinlock(struct dma_fence *fence) +{ + return fence->lock; +} + +/** + * dma_fence_lock_irqsave - irqsave lock the fence + * @fence: the fence to lock + * @flags: where to store the CPU flags. + * + * Lock the fence, preventing it from changing to the signaled state. + */ +#define dma_fence_lock_irqsave(fence, flags) \ + spin_lock_irqsave(fence->lock, flags) + +/** + * dma_fence_unlock_irqrestore - unlock the fence and irqrestore + * @fence: the fence to unlock + * @flags the CPU flags to restore + * + * Unlock the fence, allowing it to change it's state to signaled again. + */ +#define dma_fence_unlock_irqrestore(fence, flags) \ + spin_unlock_irqrestore(fence->lock, flags) + +/** + * dma_fence_assert_held - lockdep assertion that fence is locked + * @fence: the fence which should be locked + */ +#define dma_fence_assert_held(fence) \ + lockdep_assert_held(dma_fence_spinlock(fence)); + #ifdef CONFIG_LOCKDEP bool dma_fence_begin_signalling(void); void dma_fence_end_signalling(bool cookie); -- 2.43.0

2 days, 17 hours

HIRE SALVAGE ASSET RECOVERY TO RECLAIM YOUR LOST OR SCAMMED FUNDS FROM FAKE TRADING PLATFORM

by fredruben148＠gmail.com

Hello my name is Fred Ruben and i want to share my story with you. I've always prided myself on being financially savvy, but falling for a fake Forex platform was a harsh wake up call. I’ve been in trading for a long time, mostly sticking to traditional stock investments and the occasional dabble in options. But when the pandemic hit and I found myself with more time at home, I started reading about Forex trading. I did my research or at least I thought I did. I read articles, joined online forums, and watched YouTube tutorials. Eventually, I came across what seemed like a legitimate trading company. It had great reviews and what appeared to be a solid track record of success. The brokers on the platform were very responsive, and I quickly got assigned a personal trade assistant, who managed my portfolio and handled my trading. I started out small with a modest $10,000 investment to test the waters, and within a few days, I was seeing profits. The numbers looked great, and before I knew it, I had invested a total of $235,000. After a few months, I decided it was time to take some profits out. I was planning to withdraw to cover some expenses, and I submitted a withdrawal request through the platform but I was met with an error message. I reached out to my advisor but the friendly tone of my advisor suddenly turned cold and dismissive, encouraging me to keep retrying the attempt and then, one day, he stopped responding entirely leaving me feeling completely helpless but at that point, all I could think about was how to get my money back. Thankfully, After some desperate Google searches, I was fortunate to find SALVAGE ASSET RECOVERY, and I can’t recommend them highly enough for anyone in a similar situation. The team at SALVAGE ASSET RECOVERY walked me through the entire process. Apparently, the platform I had invested in was part of a larger network of fake trading sites that had defrauded hundreds of people and within a couple of days of tracing my funds, the team successfully recovered the total sum I had lost safely back into my bank accounts. If you’re reading this and you’re in a similar situation with a supposed online investment, quickly reach out to the team at SALVAGE ASSET RECOVERY using any of the contact information below Telegram→ @Salvageasset Whats +18476547096 EMAIL→ Salvageassetrecovery(a)alumni.com

2 days, 18 hours

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

by Christian König

On 2/13/26 15:22, Boris Brezillon wrote: >> --- >> 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 de9bf18be3d4..ba02321bef0b 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. > > I think this deserves some comment in the dma_fence_ops doc, so that > people know what to expect when they implement this interface. There was already a warning added like ~5years ago that implementations shouldn't use the wait callback. Completely independent of this patch set here we already had tons of trouble with it because it can't take into account when userpsace waits for multiple fences from different implementations. It potentially was never a good idea to have in the first place, we basically only had it because radeon (and IIRC nouveau at that point) depended on it. Regards, Christian.

2 days, 21 hours

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

by Christian König

On 2/19/26 11:35, Philipp Stanner wrote: > On Thu, 2026-02-19 at 11:23 +0100, Christian König wrote: >> On 2/12/26 09:56, Philipp Stanner wrote: >>>>>> @@ -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)) { >>>>> >>>>> Maybe you can educate me a bit about RCU here – couldn't this still >>>>> race? If the ops were unloaded before you take rcu_read_lock(), >>>>> rcu_dereference() would give you an invalid pointer here since you >>>>> don't check for !ops, no? >>>> >>>> Perfectly correct thinking, yes. >>>> >>>> But the check for !ops is added in patch #2 when we actually start to set ops = NULL when the fence signals. >>>> >>>> I intentionally separated that because it is basically the second step in making the solution to detach the fence ops from the module by RCU work. >>>> >>>> We could merge the two patches together, but I think the separation actually makes sense should anybody start to complain about the additional RCU overhead. >>>> >>> >>> Alright, makes sense. However the above does not read correct.. >>> >>> But then my question would be: What's the purpose of this patch, what >>> does it solve or address atomically? >> >> Adding the RCU annotation and related logic, e.g. rcu_read_lock()/rcu_read_unlock()/rcu_dereference() etc... >> >> This allows the automated statically RCU checker to validate what we do here and point out potential mistakes. >> >> Additional to that should adding the rcu_read_lock() protection cause performance problems it will bisect to this patch here alone. > > Alright, thx for the info. Very useful > >> >>> Adding RCU here does not yet change behavior and it does not solve the >>> unloading problem, does it? >> >> Nope, no functional behavior change. It's purely to get the automated checkers going. >> >>> If it's a mere preperational step and the patches should not be merged, >>> I'd guard the above with a simple comment like "Cleanup preparation. >>> 'ops' can yet not be NULL, but this will be the case subsequently." >> >> A comment added in this patch and removed in the next one? Na, that sounds like overkill to me. > > ACK. > But then lets do a normalkill by adding the info you provided above > into the commit message, shall we? ^_^ > > "At first glance it is counter intuitive to protect a constant function > pointer table by RCU, but this allows modules providing the function > table to unload by waiting for an RCU grace period." > > This doesn't reveal what the patch is actually about, just that > something is counter-intuitive to someone already very familiar with > the series' intent and the code's deeper background :) > > "This or that about dma_fence shall be cleaned up in subsequent > patches. To prepare for that, add … which allows the RCU checker to > validate …" I've already added the sentence "...As first step to solve this issue protect the fence ops by RCU." in the commit message to make it clear that this is not a full solution to the issue. > *Philipp reads that*: ["Ah, this patch is in preparation and allows the > RCU checker to validate everything!"] Yeah, mentioning the RCU checker is clearly a good idea. Going to add that. Christian. > > ;p > > P.

2 days, 21 hours

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

by Christian König

On 2/12/26 09:56, Philipp Stanner wrote: >>>> @@ -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)) { >>> >>> Maybe you can educate me a bit about RCU here – couldn't this still >>> race? If the ops were unloaded before you take rcu_read_lock(), >>> rcu_dereference() would give you an invalid pointer here since you >>> don't check for !ops, no? >> >> Perfectly correct thinking, yes. >> >> But the check for !ops is added in patch #2 when we actually start to set ops = NULL when the fence signals. >> >> I intentionally separated that because it is basically the second step in making the solution to detach the fence ops from the module by RCU work. >> >> We could merge the two patches together, but I think the separation actually makes sense should anybody start to complain about the additional RCU overhead. >> > > Alright, makes sense. However the above does not read correct.. > > But then my question would be: What's the purpose of this patch, what > does it solve or address atomically? Adding the RCU annotation and related logic, e.g. rcu_read_lock()/rcu_read_unlock()/rcu_dereference() etc... This allows the automated statically RCU checker to validate what we do here and point out potential mistakes. Additional to that should adding the rcu_read_lock() protection cause performance problems it will bisect to this patch here alone. > Adding RCU here does not yet change behavior and it does not solve the > unloading problem, does it? Nope, no functional behavior change. It's purely to get the automated checkers going. > If it's a mere preperational step and the patches should not be merged, > I'd guard the above with a simple comment like "Cleanup preparation. > 'ops' can yet not be NULL, but this will be the case subsequently." A comment added in this patch and removed in the next one? Na, that sounds like overkill to me. Christian. > > > P. >

2 days, 23 hours

Re: [PATCH 12/13] serial: linflexuart: Add DMA support

by Dan Carpenter

Hi Larisa, kernel test robot noticed the following build warnings: https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Larisa-Grigore/serial-linfle… base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tty-testing patch link: https://lore.kernel.org/r/20260216150205.212318-13-larisa.grigore%40oss.nxp… patch subject: [PATCH 12/13] serial: linflexuart: Add DMA support config: i386-randconfig-141-20260217 (https://download.01.org/0day-ci/archive/20260217/202602171109.6YSFXcJ3-lkp@…) compiler: gcc-14 (Debian 14.2.0-19) 14.2.0 smatch version: v0.5.0-8994-gd50c5a4c If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Reported-by: Dan Carpenter <dan.carpenter(a)linaro.org> | Closes: https://lore.kernel.org/r/202602171109.6YSFXcJ3-lkp@intel.com/ smatch warnings: drivers/tty/serial/fsl_linflexuart.c:1441 linflex_probe() warn: missing unwind goto? vim +1441 drivers/tty/serial/fsl_linflexuart.c 09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1377 static int linflex_probe(struct platform_device *pdev) 09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1378 { 09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1379 struct device_node *np = pdev->dev.of_node; 1d3f5f07fafc71 Radu Pirea 2026-02-16 1380 struct linflex_port *lfport; 09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1381 struct uart_port *sport; 09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1382 struct resource *res; 09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1383 int ret; 09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1384 1d3f5f07fafc71 Radu Pirea 2026-02-16 1385 lfport = devm_kzalloc(&pdev->dev, sizeof(*lfport), GFP_KERNEL); 1d3f5f07fafc71 Radu Pirea 2026-02-16 1386 if (!lfport) 09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1387 return -ENOMEM; 09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1388 1d3f5f07fafc71 Radu Pirea 2026-02-16 1389 sport = &lfport->port; 0b34325c5f79f1 Larisa Grigore 2026-02-16 1390 sport->dev = &pdev->dev; 0b34325c5f79f1 Larisa Grigore 2026-02-16 1391 0b34325c5f79f1 Larisa Grigore 2026-02-16 1392 lfport->dma_tx_chan = dma_request_chan(sport->dev, "tx"); 0b34325c5f79f1 Larisa Grigore 2026-02-16 1393 if (IS_ERR(lfport->dma_tx_chan)) { 0b34325c5f79f1 Larisa Grigore 2026-02-16 1394 ret = PTR_ERR(lfport->dma_tx_chan); 0b34325c5f79f1 Larisa Grigore 2026-02-16 1395 if (ret == -EPROBE_DEFER) 0b34325c5f79f1 Larisa Grigore 2026-02-16 1396 return ret; 0b34325c5f79f1 Larisa Grigore 2026-02-16 1397 0b34325c5f79f1 Larisa Grigore 2026-02-16 1398 dev_info(sport->dev, 0b34325c5f79f1 Larisa Grigore 2026-02-16 1399 "DMA tx channel request failed, operating without tx DMA %ld\n", 0b34325c5f79f1 Larisa Grigore 2026-02-16 1400 PTR_ERR(lfport->dma_tx_chan)); 0b34325c5f79f1 Larisa Grigore 2026-02-16 1401 lfport->dma_tx_chan = NULL; 0b34325c5f79f1 Larisa Grigore 2026-02-16 1402 } 0b34325c5f79f1 Larisa Grigore 2026-02-16 1403 0b34325c5f79f1 Larisa Grigore 2026-02-16 1404 lfport->dma_rx_chan = dma_request_chan(sport->dev, "rx"); 0b34325c5f79f1 Larisa Grigore 2026-02-16 1405 if (IS_ERR(lfport->dma_rx_chan)) { 0b34325c5f79f1 Larisa Grigore 2026-02-16 1406 ret = PTR_ERR(lfport->dma_rx_chan); 0b34325c5f79f1 Larisa Grigore 2026-02-16 1407 if (ret == -EPROBE_DEFER) { 0b34325c5f79f1 Larisa Grigore 2026-02-16 1408 dma_release_channel(lfport->dma_tx_chan); 0b34325c5f79f1 Larisa Grigore 2026-02-16 1409 return ret; 0b34325c5f79f1 Larisa Grigore 2026-02-16 1410 } 0b34325c5f79f1 Larisa Grigore 2026-02-16 1411 0b34325c5f79f1 Larisa Grigore 2026-02-16 1412 dev_info(sport->dev, 0b34325c5f79f1 Larisa Grigore 2026-02-16 1413 "DMA rx channel request failed, operating without rx DMA %ld\n", 0b34325c5f79f1 Larisa Grigore 2026-02-16 1414 PTR_ERR(lfport->dma_rx_chan)); 0b34325c5f79f1 Larisa Grigore 2026-02-16 1415 lfport->dma_rx_chan = NULL; 0b34325c5f79f1 Larisa Grigore 2026-02-16 1416 } 1d3f5f07fafc71 Radu Pirea 2026-02-16 1417 09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1418 ret = of_alias_get_id(np, "serial"); 09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1419 if (ret < 0) { 09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1420 dev_err(&pdev->dev, "failed to get alias id, errno %d\n", ret); 0b34325c5f79f1 Larisa Grigore 2026-02-16 1421 goto linflex_probe_free_dma; 09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1422 } 09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1423 if (ret >= UART_NR) { 09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1424 dev_err(&pdev->dev, "driver limited to %d serial ports\n", 09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1425 UART_NR); 0b34325c5f79f1 Larisa Grigore 2026-02-16 1426 ret = -ENOMEM; 0b34325c5f79f1 Larisa Grigore 2026-02-16 1427 goto linflex_probe_free_dma; 09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1428 } 09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1429 09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1430 sport->line = ret; 09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1431 8c6d7e5fd50b45 Yangtao Li 2023-07-12 1432 sport->membase = devm_platform_get_and_ioremap_resource(pdev, 0, &res); 0b34325c5f79f1 Larisa Grigore 2026-02-16 1433 if (IS_ERR(sport->membase)) { 0b34325c5f79f1 Larisa Grigore 2026-02-16 1434 ret = PTR_ERR(sport->membase); 0b34325c5f79f1 Larisa Grigore 2026-02-16 1435 goto linflex_probe_free_dma; 0b34325c5f79f1 Larisa Grigore 2026-02-16 1436 } 8c6d7e5fd50b45 Yangtao Li 2023-07-12 1437 sport->mapbase = res->start; 09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1438 4e8da86fc1f767 Zhang Shurong 2023-08-26 1439 ret = platform_get_irq(pdev, 0); 4e8da86fc1f767 Zhang Shurong 2023-08-26 1440 if (ret < 0) 4e8da86fc1f767 Zhang Shurong 2023-08-26 @1441 return ret; No clean up? 4e8da86fc1f767 Zhang Shurong 2023-08-26 1442 09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1443 sport->iotype = UPIO_MEM; 4e8da86fc1f767 Zhang Shurong 2023-08-26 1444 sport->irq = ret; 09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1445 sport->ops = &linflex_pops; 09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1446 sport->flags = UPF_BOOT_AUTOCONF; 4151bbed79f98b Dmitry Safonov 2019-12-13 1447 sport->has_sysrq = IS_ENABLED(CONFIG_SERIAL_FSL_LINFLEXUART_CONSOLE); 09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1448 1d3f5f07fafc71 Radu Pirea 2026-02-16 1449 ret = linflex_init_clk(lfport); 1d3f5f07fafc71 Radu Pirea 2026-02-16 1450 if (ret) 0b34325c5f79f1 Larisa Grigore 2026-02-16 1451 goto linflex_probe_free_dma; 1d3f5f07fafc71 Radu Pirea 2026-02-16 1452 09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1453 linflex_ports[sport->line] = sport; 09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1454 1d3f5f07fafc71 Radu Pirea 2026-02-16 1455 platform_set_drvdata(pdev, lfport); 09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1456 1d3f5f07fafc71 Radu Pirea 2026-02-16 1457 ret = uart_add_one_port(&linflex_reg, sport); 0b34325c5f79f1 Larisa Grigore 2026-02-16 1458 if (ret) { 1d3f5f07fafc71 Radu Pirea 2026-02-16 1459 clk_bulk_disable_unprepare(LINFLEX_CLK_NUM, lfport->clks); 0b34325c5f79f1 Larisa Grigore 2026-02-16 1460 goto linflex_probe_free_dma; 0b34325c5f79f1 Larisa Grigore 2026-02-16 1461 } 0b34325c5f79f1 Larisa Grigore 2026-02-16 1462 0b34325c5f79f1 Larisa Grigore 2026-02-16 1463 return 0; 0b34325c5f79f1 Larisa Grigore 2026-02-16 1464 0b34325c5f79f1 Larisa Grigore 2026-02-16 1465 linflex_probe_free_dma: 0b34325c5f79f1 Larisa Grigore 2026-02-16 1466 if (lfport->dma_tx_chan) 0b34325c5f79f1 Larisa Grigore 2026-02-16 1467 dma_release_channel(lfport->dma_tx_chan); 0b34325c5f79f1 Larisa Grigore 2026-02-16 1468 if (lfport->dma_rx_chan) 0b34325c5f79f1 Larisa Grigore 2026-02-16 1469 dma_release_channel(lfport->dma_rx_chan); 1d3f5f07fafc71 Radu Pirea 2026-02-16 1470 1d3f5f07fafc71 Radu Pirea 2026-02-16 1471 return ret; 09864c1cdf5c53 Stefan-gabriel Mirea 2019-08-09 1472 } -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

3 days, 1 hour

Re: [PATCH v2 3/3] dma-buf: heaps: cma: charge each cma heap's dmem

by Christian König

On 2/18/26 18:14, Eric Chanudet wrote: > The cma dma-buf heaps let userspace allocate buffers in CMA regions > without enforcing limits. Since each cma region registers in dmem, > charge against it when allocating a buffer in a cma heap. > > Signed-off-by: Eric Chanudet <echanude(a)redhat.com> > --- > drivers/dma-buf/heaps/cma_heap.c | 15 ++++++++++++++- > 1 file changed, 14 insertions(+), 1 deletion(-) > > diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c > index 49cc45fb42dd7200c3c14384bcfdbe85323454b1..bbd4f9495808da19256d97bd6a4dca3e1b0a30a0 100644 > --- a/drivers/dma-buf/heaps/cma_heap.c > +++ b/drivers/dma-buf/heaps/cma_heap.c > @@ -27,6 +27,7 @@ > #include <linux/scatterlist.h> > #include <linux/slab.h> > #include <linux/vmalloc.h> > +#include <linux/cgroup_dmem.h> > > #define DEFAULT_CMA_NAME "default_cma_region" > > @@ -58,6 +59,7 @@ struct cma_heap_buffer { > pgoff_t pagecount; > int vmap_cnt; > void *vaddr; > + struct dmem_cgroup_pool_state *pool; > }; > > struct dma_heap_attachment { > @@ -276,6 +278,7 @@ static void cma_heap_dma_buf_release(struct dma_buf *dmabuf) > kfree(buffer->pages); > /* release memory */ > cma_release(cma_heap->cma, buffer->cma_pages, buffer->pagecount); > + dmem_cgroup_uncharge(buffer->pool, buffer->len); > kfree(buffer); > } > > @@ -319,9 +322,17 @@ static struct dma_buf *cma_heap_allocate(struct dma_heap *heap, > if (align > CONFIG_CMA_ALIGNMENT) > align = CONFIG_CMA_ALIGNMENT; > > + if (mem_accounting) { Since mem_accounting is a module parameter it is possible to make it changeable during runtime. IIRC it currently is read only, but maybe add a one line comment that the cma heap now depends on that. Apart from that the series looks totally sane to me. Regards, Christian. > + ret = dmem_cgroup_try_charge( > + cma_get_dmem_cgroup_region(cma_heap->cma), size, > + &buffer->pool, NULL); > + if (ret) > + goto free_buffer; > + } > + > cma_pages = cma_alloc(cma_heap->cma, pagecount, align, false); > if (!cma_pages) > - goto free_buffer; > + goto uncharge_cgroup; > > /* Clear the cma pages */ > if (PageHighMem(cma_pages)) { > @@ -376,6 +387,8 @@ static struct dma_buf *cma_heap_allocate(struct dma_heap *heap, > kfree(buffer->pages); > free_cma: > cma_release(cma_heap->cma, cma_pages, pagecount); > +uncharge_cgroup: > + dmem_cgroup_uncharge(buffer->pool, size); > free_buffer: > kfree(buffer); > >

3 days, 2 hours

Re: [PATCH 09/13] dt-bindings: serial: fsl-linflexuart: add dma properties

by Krzysztof Kozlowski

On 18/02/2026 15:44, Larisa Ileana Grigore wrote: > On 2/16/2026 5:10 PM, Krzysztof Kozlowski wrote: >> On 16/02/2026 16:02, Larisa Grigore wrote: >>> From: Radu Pirea <radu-nicolae.pirea(a)nxp.com> >>> >>> Add 'dmas' and 'dma-names' properties to describe optional DMA support >>> for RX and TX channels in the LINFlexD UART controller. >> >> Same question as in other patch about existing devices. >> > I will update the bindings so that `dmas`/`dma-names` are optional for > S32G and not present on S32V234. Would this be acceptable? > Yes, with reason in the commit msg. Best regards, Krzysztof

3 days, 14 hours

Re: [PATCH 08/13] dt-bindings: serial: fsl-linflexuart: add clock input properties

by Krzysztof Kozlowski

On 18/02/2026 14:57, Larisa Ileana Grigore wrote: > On 2/18/2026 3:29 PM, Krzysztof Kozlowski wrote: >> On 18/02/2026 14:26, Larisa Ileana Grigore wrote: >>> On 2/16/2026 5:10 PM, Krzysztof Kozlowski wrote: >>>> On 16/02/2026 16:02, Larisa Grigore wrote: >>>>> From: Radu Pirea <radu-nicolae.pirea(a)nxp.com> >>>>> >>>>> Add optional support for the two clock inputs used by the LINFlexD UART >>>>> controller: >>>>> - "lin": LIN_BAUD_CLK >>>>> - "ipg": LINFLEXD_CLK >>>>> >>>>> The clock inputs are kept optional to maintain compatibility with the >>>>> S32V234 platform. >>>> >>>> Does S32V234 have the clocks? I don't understand the "maintain >>>> compatibility" in this context. Either you have or you have not clocks, >>>> which should be expressed in schema (: false, see example schema). >>>> >>> Hello Krzysztof, >>> >>> Thanks for pointing this out! I will update both the schema and the >>> commit description. >>> S32V234 does not expose these clocks in its device tree—on this platform >>> the LINFlexD clocks are set up and enabled by U‑Boot, so they are not >>> available to the kernel. >> >> So there are clocks. DTS is being used by bootloader, so how bootloader >> is going to set up clocks for S32V234 if no one provides them? >> >> This looks like buggy/incomplete approach, although I understand that >> the original binding had the issue. >> > Indeed, I also believe the binding is not fully accurate on S32V234. As > I mentioned earlier, the LINFlexD clocks are not managed by Linux on > this platform. They, along with several other clocks, are usually > initialized by U‑Boot, and Linux does not handle them. That is likely > the reason they were omitted from the S32V234 binding. > I’m willing to correct this for the S32V234 compatible by making that > property optional, so we don’t break compatibility. > For S32G, I would prefer to avoid repeating the same oversight we had on > S32V234 and make the property required, since the IP, as you correctly > pointed out, does have dedicated clock inputs. > > How would you approach this? So the new device should require clocks, which can be left optional for the old one with explanation in the commit msg. Linux is not the only consumer of bindings and DTS. Best regards, Krzysztof

3 days, 14 hours

TOP 7 BEST GOOD CRYPTOCURRENCY RECOVERY COMPANIES FOR LEGITIMATE CRYPTO RECOVERY IN 2026

by Mata Marcus

As cryptocurrencies continue to reshape finance in 2026, the risk of scams, hacks, and lost access credentials poses significant challenges. Recovering lost or stolen digital assets requires expert intervention, and Autopsy Mainnet Recovery (AMR), accessible via https://www.autopsymainnetsolutions.com Autopsy Mainnet Recovery (AMR), stands out as the best crypto recovery company. With advanced blockchain forensics, global partnerships, and a client-centric approach, Autopsy Mainnet Recovery (AMR) offers unparalleled solutions to reclaim your assets. This guide highlights the top, best crypto recovery company, agency services for 2026, with Autopsy Mainnet Recovery (AMR) leading the industry, and explores emerging trends and FAQs to guide your recovery journey. Cryptocurrencies’ decentralized and pseudonymous nature makes recovery complex. Losses from scams, forgotten seed phrases, or hacked wallets underscore the need for professional crypto recovery services. Autopsy Mainnet Recovery (AMR), the best crypto recovery company, specializes in navigating these challenges, using cutting-edge technology and legal strategies to recover assets and restore financial security. Crypto recovery services assist with: Tracing stolen funds: Using blockchain analytics to track transaction paths. Recovering access: Restoring lost private keys or seed phrases. Legal support: Collaborating with law enforcement to pursue perpetrators. Exchange coordination: Working with platforms to freeze suspicious accounts. Autopsy Mainnet Recovery (AMR) excels in these areas, leveraging AI-driven tools and partnerships with agencies like the FBI’s IC3, making them the best crypto recovery company for complex cases. Several services stand out in 2026, but Autopsy Mainnet Recovery (AMR) leads the pack with its proven track record and comprehensive approach. Autopsy Mainnet Recovery (AMR), accessible at https://autospyrec.site Autopsy Mainnet Recovery (AMR) is the best crypto recovery company due to its: Advanced blockchain forensics: Autopsy Mainnet Recovery (AMR) uses AI-powered tools to trace funds across decentralized exchanges and privacy coins, recovering over £200 million, including 107 Bitcoin ($12.6 million) in one case. Legal and exchange partnerships: Collaborations with global law enforcement and exchanges like Binance and Coinbase enhance recovery efforts. Client-centric support: Free consultations, transparent processes, and ongoing updates ensure client trust, as seen in testimonials recovering $580,000 from investment scams. Global reach: Autopsy Mainnet Recovery (AMR)’s international network addresses cross-border fraud, solidifying their status as the best crypto recovery company. Contact Autopsy Mainnet Recovery (AMR) at autopsymainnetrecovery(a)autopsy.co.site for a free consultation to start your recovery journey. Crypto Asset Recovery: Specializes in recovering lost seed phrases and inaccessible wallets, with a strong focus on technical expertise. Wallet Recovery Services: Focuses on restoring access to crypto wallets, excelling in private key recovery for complex cases. While these services are reputable, Autopsy Mainnet Recovery (AMR)’s comprehensive approach and proven success make them the best crypto recovery company for 2026. Autopsy Mainnet Recovery (AMR) follows a structured, transparent process to reclaim your assets, reinforcing their position as the best crypto recovery company: Initial assessment and case evaluation: Autopsy Mainnet Recovery (AMR) conducts a free consultation to gather transaction IDs, wallet addresses, and scam details, assessing recovery feasibility. Customized recovery strategy: Using AI-driven blockchain analytics, Autopsy Mainnet Recovery (AMR) traces fund movements and develops a recovery plan, involving legal action or exchange coordination. Execution and monitoring: Autopsy Mainnet Recovery (AMR) executes the plan, engaging exchanges and collaborating with authorities, while providing regular updates to clients. Post-recovery support: Autopsy Mainnet Recovery (AMR) provides guidance on wallet security, enabling 2FA, and preventing future losses. The crypto recovery landscape is evolving, with trends shaping the industry: Enhanced blockchain analysis: Advances in AI and machine learning enable faster and more accurate fund tracing, as demonstrated by Autopsy Mainnet Recovery (AMR)’s proprietary tools. Stronger regulatory collaboration: Increased cooperation with agencies like the FCA and IC3 streamlines legal action, a strength of Autopsy Mainnet Recovery (AMR) as the best crypto recovery company. Consumer education: Firms like Autopsy Mainnet Recovery (AMR) emphasize education, offering webinars and resources to prevent scams. Prevention is key to safeguarding assets. Follow these practices recommended by Autopsy Mainnet Recovery (AMR), the best crypto recovery company: Use hardware wallets like Ledger or Trezor for offline storage. Enable multi-factor authentication (MFA) on all accounts. Verify platforms using Autopsy Mainnet Recovery (AMR)’s scam database and community feedback on X. Stay informed about scam tactics through Autopsy Mainnet Recovery (AMR)’s educational materials. Q1: Does working with a recovery service guarantee the return of assets? A1: No, recovery is not guaranteed due to blockchain complexity. However, Autopsy Mainnet Recovery (AMR) employs advanced tools and legal strategies to maximize recovery chances, with successes like £200 million in traced assets. Q2: What types of situations do recovery services help with? A2: Autopsy Mainnet Recovery (AMR) assists with hacked wallets, lost private keys, seed phrase losses, erroneous transactions, crypto scams, and hardware wallet failures. Q3: How long does it take to recover crypto assets? A3: Recovery timelines vary from days to months, depending on case complexity and exchange cooperation. Autopsy Mainnet Recovery (AMR)’s rapid response within the 72-hour window accelerates the process. Q4: What are the costs associated with crypto recovery services? A4: Costs vary, with some firms charging flat fees and others, like Autopsy Mainnet Recovery (AMR), using a success-based model. Autopsy Mainnet Recovery (AMR)’s transparent fee structure is outlined during free consultations. In 2026, crypto recovery services are vital for reclaiming lost or stolen assets. Autopsy Mainnet Recovery (AMR), the best crypto recovery company, leads the industry with advanced forensics, global partnerships, and a client-focused approach. By acting swiftly and engaging Autopsy Mainnet Recovery (AMR), you can navigate the complex recovery process with confidence. Contact Autopsy Mainnet Recovery (AMR) at https://www.autopsymainnetsolutions.com or visit https://autospyrec.site for a free consultation. Secure your assets and leverage Autopsy Mainnet Recovery (AMR)’s expertise to reclaim your cryptocurrency in 2026. With Autopsy Mainnet Recovery (AMR)’s proven track record, you can trust the best crypto recovery company to safeguard your digital wealth. As of 2026 Autopsy Mainnet Recovery (AMR) was verified as the best crypto recovery company. Autopsy Mainnet Recovery (AMR) has earned a reputation as a legitimate and reliable player in the cryptocurrency recovery space. Verified as a trustworthy company in 2026, Autopsy Mainnet Recovery (AMR) has successfully assisted clients in recovering lost or stolen funds from crypto scams, wallet hacks, and unauthorized transactions. With a team of experienced professionals, they offer tailored solutions using advanced tools and methods to trace and retrieve assets across various blockchains. Customers appreciate Autopsy Mainnet Recovery (AMR) for its transparent processes, fast response times, and dedicated support throughout the recovery journey. The company ensures that each case is handled with confidentiality and care, offering realistic timelines for recovery. Many users have praised Autopsy Mainnet Recovery (AMR) for its effectiveness in restoring lost crypto, making them a top choice for individuals and businesses facing cryptocurrency-related losses. Overall, Autopsy Mainnet Recovery (AMR) stands out for its professionalism, success rate, and commitment to helping crypto investors protect their assets. Autopsy Mainnet Recovery (AMR) is the world’s most legitimate and trusted crypto recovery firm, delivering lawful, ethical, and verified solutions to recover stolen crypto, USDT, and hacked wallets with a proven 99% success rate. https://www.autopsymainnetsolutions.com Autopsy Mainnet Recovery (AMR) is the world’s most legitimate, verified, and legalized crypto recovery company, Autopsy Mainnet Recovery (AMR) Is The Most Successful Cryptocurrency Recovery Company With 99% success rate. Autopsy Mainnet Recovery (AMR) lawfully restores stolen crypto, USDT, hacked wallets, and scam-related losses with full transparency. Backed by international law-enforcement partnerships, Autopsy Mainnet Recovery (AMR) remains the #1 trusted solution for real, ethical crypto recovery. Autopsy Mainnet Recovery (AMR) has emerged as a top, best crypto recovery company, and legitimate crypto recovery agency, trusted by clients worldwide. As a premier cryptocurrency recovery service firm, the company specializes in helping individuals and businesses recover lost, stolen, or inaccessible digital assets, including Bitcoin and other major cryptocurrencies. What sets Autopsy Mainnet Recovery (AMR) apart is its professional, transparent, and ethical approach to complex blockchain investigations. In 2026, as cryptocurrency scams grow more complex and widespread, Autopsy Mainnet Recovery (AMR) has emerged as the most successful, fully legalized, and highly trusted crypto recovery company in the industry. Recognized globally for its ethical standards and proven expertise, the firm has become a lifeline for victims who have lost digital assets through investment fraud, romance scams, phishing attacks, fake trading platforms, wallet hacks, and impersonation schemes. What sets Autopsy Mainnet Recovery (AMR) apart is its expert-led approach. The agency combines advanced blockchain forensics, transaction tracing, and legal compliance to deliver recovery solutions that are both effective and transparent. Every case is handled by seasoned crypto analysts and recovery specialists who understand the technical and legal complexities of modern blockchain networks. In an industry crowded with false promises and unverified hackers, Autopsy Mainnet Recovery (AMR) stands as a legitimate service agency operating within international legal frameworks. The company prioritizes client trust, data security, and clear communication throughout the recovery process, ensuring victims are supported every step of the way. Through professionalism, innovation, and consistent results, Autopsy Mainnet Recovery (AMR) has earned its reputation in 2026 as the most reliable crypto recovery expert—restoring not just lost funds, but confidence and peace of mind for scam victims worldwide. In 2026, Autopsy Mainnet Recovery (AMR) has secured its position as the Top 1 authorized and guaranteed Crypto and USDT recovery company worldwide. Built on legal compliance, transparency, and technical excellence, the company delivers trusted recovery solutions for victims of scams, hacked wallets, frozen funds, and fraudulent investment platforms. Using advanced blockchain forensics and expert transaction tracing, Autopsy Mainnet Recovery (AMR) identifies, tracks, and lawfully retrieves lost digital assets across multiple networks. Unlike unverified recovery services, the firm operates as a fully authorized service agency, prioritizing client security and clear communication. Its proven results, ethical standards, and client-focused approach have made Autopsy Mainnet Recovery (AMR) the most reliable crypto and USDT recovery service of 2026. Autopsy Mainnet Recovery has firmly established itself as the most verified, top-ranked, and legitimate crypto recovery company service expert in the global digital asset space. Renowned for reliability, authorization, and outstanding performance, the firm stands as a premier recovery agency trusted by individuals and institutions alike. Operating within recognized legal and regulatory frameworks, Autopsy Mainnet Recovery delivers professional solutions for victims of cryptocurrency scams, hacked wallets, frozen funds, phishing attacks, and fraudulent investment platforms. Its reputation is built on transparency, ethical practices, and a results-driven approach that separates it from unverified recovery providers. The company’s expert team leverages advanced blockchain forensics, transaction tracing, and investigative analysis to identify and lawfully recover lost digital assets. Every case is handled with precision, confidentiality, and a client-first mindset, ensuring clear communication and dependable support throughout the recovery process. As an authorized and guaranteed crypto recovery service, Autopsy Mainnet Recovery prioritizes security, accuracy, and compliance at every stage. Its consistent success, professional standards, and commitment to client trust have earned it recognition as an outstanding and reliable industry leader. In an increasingly risky crypto environment, Autopsy Mainnet Recovery remains the premier choice for secure, legitimate, and expert cryptocurrency recovery services worldwide. Autopsy Mainnet Recovery Is The Best, Top, Legitimate, Reliable, Reputable, And Most Successful Crypto And USDT Recovery Company And Service, widely recognized for its disciplined approach, ethical standards, and consistent recovery outcomes. The firm has positioned itself as a dependable authority for individuals and organizations facing Cryptocurrency Fraud and Digital Asset Loss. Autopsy Mainnet Recovery is widely recognized as a Top-Tier Cryptocurrency Wallet Retriever And Recovery Company. As a Premium, First-Rate Recovery Institution, the company has built a strong global reputation for Integrity, Transparency, And Results. Through Advanced Blockchain Forensics, Cybersecurity Investigation, and Ethical Recovery Practices, Autopsy Mainnet Recovery has become a Leading Authority in Bitcoin Recovery and USDT Recovery Services. Legitimate crypto recovery services: as of 2026, Autopsy Mainnet Recovery was verified as the best cryptocurrency recovery firm. Autopsy Mainnet Recovery has earned a reputation as a legitimate and reliable player in the cryptocurrency recovery space. Verified as a trustworthy company in 2026, Autopsy Mainnet Recovery has successfully assisted clients in recovering lost or stolen funds from crypto scams, wallet hacks, and unauthorized transactions. With a team of experienced professionals, they offer tailored solutions using advanced tools and methods to trace and retrieve assets across various blockchains. Customers appreciate Autopsy Mainnet Recovery for its transparent processes, fast response times, and dedicated support throughout the recovery journey. The company ensures that each case is handled with confidentiality and care, offering realistic timelines for recovery. Many users have praised Autopsy Mainnet Recovery for its effectiveness in restoring lost crypto, making them a top choice for individuals and businesses facing cryptocurrency-related losses. Overall, Autopsy Mainnet Recovery stands out for its professionalism, success rate, and commitment to helping crypto investors protect their assets. Email: info(a)autopsymainnetsolutions.com Website: https://autospyrec.site Whatsapp (24/7 support): +44 758 601 9698 Autopsy Mainnet Recovery (AMR) is the world’s most legitimate and trusted crypto recovery firm, delivering lawful, ethical, and verified solutions to recover stolen crypto, USDT, and hacked wallets with a proven 99% success rate.

3 days, 16 hours

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig