Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

24 participants
6306 discussions

by joelwest689＠gmail.com

By combining cross-chain tracing, rapid response, and data-driven investigation, Cipher Rescue Chain stands as the global benchmark for crypto recovery. Every traced transaction, every reconstructed path, and every recovered asset reinforces the same conclusion: with the right forensic expertise, recovery is not only possible—it is highly achievable.

19 minutes

Re: [PATCH] dma-buf: fix order of trace and fput

by Christian König

On 4/9/26 14:38, Andi Shyti wrote: > Hi Christian, > >> @@ -845,9 +845,8 @@ void dma_buf_put(struct dma_buf *dmabuf) >> if (WARN_ON(!dmabuf || !dmabuf->file)) >> return; >> >> - fput(dmabuf->file); >> - >> DMA_BUF_TRACE(trace_dma_buf_put, dmabuf); >> + fput(dmabuf->file); > > funny, I just found out I sent the exact same patch, just few > minutes later :-) [*] I liked your patch better since it has more accurate tags. Just reviewed and pushed that one to drm-misc-fixes, should land upstream by the end of the week. Regards, Christian. > > Andi > >> } > > [*] https://lore.kernel.org/all/20260408123916.2604101-2-andi.shyti@kernel.org/

1 hour, 43 minutes

Re: [PATCH RFC 12/26] vfio/pci: Change the DMA-buf exporter to use mapping_type

by Jason Gunthorpe

On Mon, Apr 13, 2026 at 04:29:59PM +0800, Baolu Lu wrote: > On 2/18/26 08:11, Jason Gunthorpe wrote: > > Simple conversion to add a match_mapping() callback that offers an > > exporter SGT mapping type. Later patches will add a physical address > > exporter so go straight to adding the match_mapping() function. > > > > The check for attachment->peer2peer is replaced with setting > > exporter_requires_p2p=true. VFIO always uses MMIO memory. > > > > Signed-off-by: Jason Gunthorpe <jgg(a)nvidia.com> > > --- > > drivers/vfio/pci/vfio_pci_dmabuf.c | 31 +++++++++++++++++++++++++----- > > 1 file changed, 26 insertions(+), 5 deletions(-) > > > > diff --git a/drivers/vfio/pci/vfio_pci_dmabuf.c b/drivers/vfio/pci/vfio_pci_dmabuf.c > > index d4d0f7d08c53e2..c7addef5794abf 100644 > > --- a/drivers/vfio/pci/vfio_pci_dmabuf.c > > +++ b/drivers/vfio/pci/vfio_pci_dmabuf.c > > @@ -25,9 +25,6 @@ static int vfio_pci_dma_buf_attach(struct dma_buf *dmabuf, > > { > > struct vfio_pci_dma_buf *priv = dmabuf->priv; > > - if (!attachment->peer2peer) > > - return -EOPNOTSUPP; > > - > > if (priv->revoked) > > return -ENODEV; > > @@ -75,11 +72,35 @@ static void vfio_pci_dma_buf_release(struct dma_buf *dmabuf) > > kfree(priv); > > } > > -static const struct dma_buf_ops vfio_pci_dmabuf_ops = { > > - .attach = vfio_pci_dma_buf_attach, > > +static const struct dma_buf_mapping_sgt_exp_ops vfio_pci_dma_buf_sgt_ops = { > > .map_dma_buf = vfio_pci_dma_buf_map, > > .unmap_dma_buf = vfio_pci_dma_buf_unmap, > > +}; > > + > > +static int vfio_pci_dma_buf_match_mapping(struct dma_buf_match_args *args) > > +{ > > + struct vfio_pci_dma_buf *priv = args->dmabuf->priv; > > + struct dma_buf_mapping_match sgt_match[1]; > > + > > + dma_resv_assert_held(priv->dmabuf->resv); > > My understanding of this lock assertion is that priv and the underlying > priv->vdev are accessed within this function. Therefore, the lock is > necessary to protect them. Do I understand it right? It is because we NULL priv->vdev on the cleanup path I'm not sure why my test kernel didn't hit lockdep failures but yes this looks incorrect. > However, callers - for example, dma_buf_mapping_attach() - do not > acquire dma_resv_lock() before calling this function. So kernel traces > will always be triggered. I think this is the fix: diff --git a/drivers/vfio/pci/vfio_pci_dmabuf.c b/drivers/vfio/pci/vfio_pci_dmabuf.c index 9e7e8e7719d1bd..3e31ffb03ddd9a 100644 --- a/drivers/vfio/pci/vfio_pci_dmabuf.c +++ b/drivers/vfio/pci/vfio_pci_dmabuf.c @@ -12,6 +12,7 @@ MODULE_IMPORT_NS("DMA_BUF"); struct vfio_pci_dma_buf { struct dma_buf *dmabuf; struct vfio_pci_core_device *vdev; + struct pci_dev *pdev; struct list_head dmabufs_elm; size_t size; struct phys_vec *phys_vec; @@ -92,6 +93,7 @@ static void vfio_pci_dma_buf_release(struct dma_buf *dmabuf) up_write(&priv->vdev->memory_lock); vfio_device_put_registration(&priv->vdev->vdev); } + pci_dev_put(priv->pdev); kfree(priv->phys_vec); kfree(priv); } @@ -143,18 +145,9 @@ static int vfio_pci_dma_buf_match_mapping(struct dma_buf_match_args *args) struct vfio_pci_dma_buf *priv = args->dmabuf->priv; struct dma_buf_mapping_match sgt_match[2]; - dma_resv_assert_held(priv->dmabuf->resv); - - /* - * Once we pass vfio_pci_dma_buf_cleanup() the dmabuf will never be - * usable again. - */ - if (!priv->vdev) - return -ENODEV; - sgt_match[0] = DMA_BUF_EMAPPING_PAL(&vfio_pci_dma_buf_pal_ops); sgt_match[1] = DMA_BUF_EMAPPING_SGT_P2P(&vfio_pci_dma_buf_sgt_ops, - priv->vdev->pdev); + priv->pdev); return dma_buf_match_mapping(args, sgt_match, ARRAY_SIZE(sgt_match)); } @@ -323,6 +316,7 @@ int vfio_pci_core_feature_dma_buf(struct vfio_pci_core_device *vdev, u32 flags, goto err_dev_put; } + priv->pdev = pci_dev_get(vdev->pdev); kref_init(&priv->kref); init_completion(&priv->comp);

2 hours, 42 minutes

[PATCH RFC 00/26] Add DMA-buf mapping types and convert vfio/iommufd to use them

by Jason Gunthorpe

Since its introduction, DMA-buf has only supported using scatterlist for the exporter and importer to exchange address information. This is not sufficient for all use cases as dma_addr_t is a very specific and limited type that should not be abused for things unrelated to the DMA API. There are several motivations for addressing this now: 1) VFIO to IOMMUFD and KVM requires a physical address, not a dma_addr_t scatterlist, it cannot be represented in the scatterlist structure 2) xe vGPU requires the host driver to accept a DMABUF from VFIO of its own VF and convert it into an internal VRAM address on the PF 3) We are starting to look at replacement datastructures for scatterlist 4) Ideas around UALink/etc are suggesting not using the DMA API None of these can sanely be achieved using scatterlist. Introduce a new mechanism called "mapping types" which allows DMA-buf to work with more map/unmap options than scatterlist. Each mapping type encompasses a full set of functions and data unique to itself. The core code provides a match-making system to select the best type offered by the exporter and importer to be the active mapping type for the attachment. Everything related to scatterlist is moved into a DMA-buf SGT mapping type, and into the "dma_buf_sgt_*" namespace for clarity. Existing exporters are moved over to explicitly declare SGT mapping types and importers are adjusted to use the dma_buf_sgt_* named importer helpers. Mapping types are designed to be extendable, a driver can declare its own mapping type for its internal private interconnect and use that without having to adjust the core code. The new attachment sequence starts with the importing driver declaring what mapping types it can accept: struct dma_buf_mapping_match imp_match[] = { DMA_BUF_IMAPPING_MY_DRIVER(dev, ...), DMA_BUF_IMAPPING_SGT(dev, false), }; attach = dma_buf_mapping_attach(dmabuf, imp_match, ...) Most drivers will do this via a dma_buf_sgt_*attach() helper. The exporting driver can then declare what mapping types it can supply: int exporter_match_mapping(struct dma_buf_match_args *args) { struct dma_buf_mapping_match exp_match[] = { DMA_BUF_EMAPPING_MY_DRIVER(my_ops, dev, ...), DMA_BUF_EMAPPING_SGT(sgt_ops, dev, false), DMA_BUF_EMAPPING_PAL(PAL_ops), }; return dma_buf_match_mapping(args, exp_match, ...); } Most drivers will do this via a helper: static const struct dma_buf_ops ops = { DMA_BUF_SIMPLE_SGT_EXP_MATCH(map_func, unmap_func) }; During dma_buf_mapping_attach() the core code will select a mutual match between the importer and exporter and record it as the active match in the attach->map_type. Each mapping type has its own types/function calls for mapping/unmapping, and storage in the attach->map_type for its information. As such each mapping type can offer function signatures and data that exactly matches its needs. This series goes through a sequence of: 1) Introduce the basic mapping type framework and the main components of the SGT mapping type 2) Automatically make all existing exporters and importers use core generated SGT mapping types so every attachment has a SGT mapping type 3) Convert all exporter drivers to natively create a SGT mapping type 4) Move all dma_buf_* functions and types that are related to SGT into dma_buf_sgt_* 5) Remove all the now-unused items that have been moved into SGT specific structures. 6) Demonstrate adding a new Physical Address List alongside SGT. Due to the high number of files touched I would expect this to be broken into phases, but this shows the entire picture. This is on github: https://github.com/jgunthorpe/linux/commits/dmabuf_map_type It is a followup to the discussion here: https://lore.kernel.org/dri-devel/20251027044712.1676175-1-vivek.kasireddy@… Jason Gunthorpe (26): dma-buf: Introduce DMA-buf mapping types dma-buf: Add the SGT DMA mapping type dma-buf: Add dma_buf_mapping_attach() dma-buf: Route SGT related actions through attach->map_type dma-buf: Allow single exporter drivers to avoid the match_mapping function drm: Check the SGT ops for drm_gem_map_dma_buf() dma-buf: Convert all the simple exporters to use SGT mapping type drm/vmwgfx: Use match_mapping instead of dummy calls accel/habanalabs: Use the SGT mapping type drm/xe/dma-buf: Use the SGT mapping type drm/amdgpu: Use the SGT mapping type vfio/pci: Change the DMA-buf exporter to use mapping_type dma-buf: Update dma_buf_phys_vec_to_sgt() to use the SGT mapping type iio: buffer: convert to use the SGT mapping type functionfs: convert to use the SGT mapping type dma-buf: Remove unused SGT stuff from the common structures treewide: Rename dma_buf_map_attachment(_unlocked) to dma_buf_sgt_ treewide: Rename dma_buf_unmap_attachment(_unlocked) to dma_buf_sgt_* treewide: Rename dma_buf_attach() to dma_buf_sgt_attach() treewide: Rename dma_buf_dynamic_attach() to dma_buf_sgt_dynamic_attach() dma-buf: Add the Physical Address List DMA mapping type vfio/pci: Add physical address list support to DMABUF iommufd: Use the PAL mapping type instead of a vfio function iommufd: Support DMA-bufs with multiple physical ranges iommufd/selftest: Check multi-phys DMA-buf scenarios dma-buf: Add kunit tests for mapping type Documentation/gpu/todo.rst | 2 +- drivers/accel/amdxdna/amdxdna_gem.c | 14 +- drivers/accel/amdxdna/amdxdna_ubuf.c | 10 +- drivers/accel/habanalabs/common/memory.c | 54 ++- drivers/accel/ivpu/ivpu_gem.c | 10 +- drivers/accel/ivpu/ivpu_gem_userptr.c | 11 +- drivers/accel/qaic/qaic_data.c | 8 +- drivers/dma-buf/Makefile | 1 + drivers/dma-buf/dma-buf-mapping.c | 186 ++++++++- drivers/dma-buf/dma-buf.c | 180 ++++++--- drivers/dma-buf/heaps/cma_heap.c | 12 +- drivers/dma-buf/heaps/system_heap.c | 13 +- drivers/dma-buf/st-dma-mapping.c | 373 ++++++++++++++++++ drivers/dma-buf/udmabuf.c | 8 +- drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 98 +++-- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 6 +- drivers/gpu/drm/armada/armada_gem.c | 33 +- drivers/gpu/drm/drm_gem_shmem_helper.c | 2 +- drivers/gpu/drm/drm_prime.c | 31 +- drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 18 +- drivers/gpu/drm/i915/gem/i915_gem_object.c | 2 +- .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 8 +- .../gpu/drm/i915/gem/selftests/mock_dmabuf.c | 8 +- drivers/gpu/drm/msm/msm_gem_prime.c | 7 +- drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 11 +- drivers/gpu/drm/tegra/gem.c | 33 +- drivers/gpu/drm/virtio/virtgpu_prime.c | 23 +- drivers/gpu/drm/vmwgfx/vmwgfx_prime.c | 32 +- drivers/gpu/drm/xe/xe_bo.c | 18 +- drivers/gpu/drm/xe/xe_dma_buf.c | 61 +-- drivers/iio/industrialio-buffer.c | 15 +- drivers/infiniband/core/umem_dmabuf.c | 15 +- drivers/iommu/iommufd/io_pagetable.h | 4 +- drivers/iommu/iommufd/iommufd_private.h | 8 - drivers/iommu/iommufd/iommufd_test.h | 7 + drivers/iommu/iommufd/pages.c | 85 ++-- drivers/iommu/iommufd/selftest.c | 177 ++++++--- .../media/common/videobuf2/videobuf2-core.c | 2 +- .../common/videobuf2/videobuf2-dma-contig.c | 26 +- .../media/common/videobuf2/videobuf2-dma-sg.c | 21 +- .../common/videobuf2/videobuf2-vmalloc.c | 13 +- .../platform/nvidia/tegra-vde/dmabuf-cache.c | 9 +- drivers/misc/fastrpc.c | 21 +- drivers/tee/tee_heap.c | 13 +- drivers/usb/gadget/function/f_fs.c | 11 +- drivers/vfio/pci/vfio_pci_dmabuf.c | 79 ++-- drivers/xen/gntdev-dmabuf.c | 29 +- include/linux/dma-buf-mapping.h | 297 ++++++++++++++ include/linux/dma-buf.h | 168 ++++---- io_uring/zcrx.c | 9 +- net/core/devmem.c | 14 +- samples/vfio-mdev/mbochs.c | 10 +- sound/soc/fsl/fsl_asrc_m2m.c | 12 +- tools/testing/selftests/iommu/iommufd.c | 43 ++ tools/testing/selftests/iommu/iommufd_utils.h | 17 + 55 files changed, 1764 insertions(+), 614 deletions(-) create mode 100644 drivers/dma-buf/st-dma-mapping.c base-commit: c63e5a50e1dd291cd95b04291b028fdcaba4c534 -- 2.43.0

3 hours, 27 minutes

Re: [PATCH] dma-fence: Clarify external lock use case in dma_fence_init() docs

by Maíra Canal

Hi Philipp, On 4/13/26 03:47, Philipp Stanner wrote: > On Sat, 2026-04-11 at 15:47 -0300, Maíra Canal wrote: >> The kerneldoc comment on dma_fence_init() and dma_fence_init64() describe >> the legacy reason to pass an external lock as a need to prevent multiple >> fences "from signaling out of order". However, this wording is a bit >> misleading: a shared spinlock does not (and cannot) prevent the signaler >> from signaling out of order. Signaling order is the driver's responsibility >> regardless of whether the lock is shared or per-fence. >> >> What a shared lock actually provides is serialization of signaling and >> observation across fences in a given context, so that observers never >> see a later fence signaled while an earlier one is not. >> >> Reword both comments to describe this more accurately. >> >> Signed-off-by: Maíra Canal <mcanal(a)igalia.com> >> --- >> >> Hi, >> >> While reading the documentation, I found this particular paragraph quite >> hard to understand. As I understand it, locks don't enforce order, only >> serialization, but the paragraph seems to communicate the other way around. > > Yes, 100%. > That's one of the reasons why Christian recently moved to using inline- > locks. > > > >> Due to that, I had the impression that the current wording can be >> misleading for driver developers. >> >> I'm proposing a new wording to better describe the use case of the >> external lock based on my understanding, but it would be great to hear >> the feedback and suggestions from more experienced developers who might >> have more insight about these legacy use cases. >> >> Best regards, >> - Maíra >> >> drivers/dma-buf/dma-fence.c | 12 ++++++++---- >> 1 file changed, 8 insertions(+), 4 deletions(-) >> >> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c >> index 1826ba73094c..bdc29d1c1b5c 100644 >> --- a/drivers/dma-buf/dma-fence.c >> +++ b/drivers/dma-buf/dma-fence.c >> @@ -1102,8 +1102,10 @@ __dma_fence_init(struct dma_fence *fence, const struct dma_fence_ops *ops, >> * to check which fence is later by simply using dma_fence_later(). >> * >> * It is strongly discouraged to provide an external lock because this couples >> - * lock and fence life time. This is only allowed for legacy use cases when >> - * multiple fences need to be prevented from signaling out of order. >> + * lock and fence lifetime. This is only allowed for legacy use cases that need >> + * a shared lock to serialize signaling and observation of fences within a >> + * context, so that observers never see a later fence signaled while an earlier >> + * one isn't. > > I would probably delete the explanation altogether and just state > "allowed for legacy reasons". The legacy people know why it's allowed, > and new users don't need to care. Same below of course. Actually, I ended up in this part of the documentation as I'm thinking about dropping the external lock in v3d driver. I was reading the docs exactly to know if v3d is a legacy use case (spoiler: it isn't) and I got confused by the current wording. So, I think there is value in documenting the legacy use cases for the external lock. Maybe, instead of "strongly discouraged", we could add a disclaimer like: "New drivers MUST NOT use an external lock because...". What do you think? Best regards, - Maíra > > > Thx > P. > >> */ >> void >> dma_fence_init(struct dma_fence *fence, const struct dma_fence_ops *ops, >> @@ -1129,8 +1131,10 @@ EXPORT_SYMBOL(dma_fence_init); >> * to check which fence is later by simply using dma_fence_later(). >> * >> * It is strongly discouraged to provide an external lock because this couples >> - * lock and fence life time. This is only allowed for legacy use cases when >> - * multiple fences need to be prevented from signaling out of order. >> + * lock and fence lifetime. This is only allowed for legacy use cases that need >> + * a shared lock to serialize signaling and observation of fences within a >> + * context, so that observers never see a later fence signaled while an earlier >> + * one isn't. >> */ >> void >> dma_fence_init64(struct dma_fence *fence, const struct dma_fence_ops *ops, >

3 hours, 43 minutes

Re: [PATCH 2/3] dma-fence: Fix potential tracepoint null pointer dereferences

by Christian König

On 4/13/26 12:05, Tvrtko Ursulin wrote: > Trace_dma_fence_signaled, trace_dma_fence_wait_end and > trace_dma_fence_destroy can all dereference a null fence->ops pointer > after it has been reset on fence signalling. > > Lets use the safe string getters for most tracepoints to a void this. > > But for the signalling tracepoint, we move it to before the fence->ops > is reset and special case its definition in order to avoid losing the > driver and timeline information. > > Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin(a)igalia.com> > Fixes: 541c8f2468b9 ("dma-buf: detach fence ops on signal v3") > Cc: Christian König <christian.koenig(a)amd.com> > Cc: Philipp Stanner <phasta(a)kernel.org> > Cc: Boris Brezillon <boris.brezillon(a)collabora.com> > Cc: linux-media(a)vger.kernel.org > Cc: linaro-mm-sig(a)lists.linaro.org > --- > drivers/dma-buf/dma-fence.c | 3 ++- > include/trace/events/dma_fence.h | 29 +++++++++++++++++++++++++++-- > 2 files changed, 29 insertions(+), 3 deletions(-) > > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c > index a2aa82f4eedd..b3bfa6943a8e 100644 > --- a/drivers/dma-buf/dma-fence.c > +++ b/drivers/dma-buf/dma-fence.c > @@ -363,6 +363,8 @@ void dma_fence_signal_timestamp_locked(struct dma_fence *fence, > &fence->flags))) > return; > > + trace_dma_fence_signaled(fence); > + > /* > * When neither a release nor a wait operation is specified set the ops > * pointer to NULL to allow the fence structure to become independent > @@ -377,7 +379,6 @@ void dma_fence_signal_timestamp_locked(struct dma_fence *fence, > > fence->timestamp = timestamp; > set_bit(DMA_FENCE_FLAG_TIMESTAMP_BIT, &fence->flags); > - trace_dma_fence_signaled(fence); > > list_for_each_entry_safe(cur, tmp, &cb_list, node) { > INIT_LIST_HEAD(&cur->node); > diff --git a/include/trace/events/dma_fence.h b/include/trace/events/dma_fence.h > index 3abba45c0601..220bf71446e8 100644 > --- a/include/trace/events/dma_fence.h > +++ b/include/trace/events/dma_fence.h > @@ -9,12 +9,37 @@ > > 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)) That requires that we hold the RCU read side lock while doing the trace. Not sure if that can be done inside the DECLARE_EVENT_CLASS() macro. > + __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, > +DECLARE_EVENT_CLASS(dma_fence_ops, > > TP_PROTO(struct dma_fence *fence), > > @@ -67,7 +92,7 @@ DEFINE_EVENT(dma_fence, dma_fence_enable_signal, > TP_ARGS(fence) > ); > > -DEFINE_EVENT(dma_fence, dma_fence_signaled, > +DEFINE_EVENT(dma_fence_ops, dma_fence_signaled, The signal trace event is actually unproblematic. The question is more what to do with the release event. Regards, Christian. > > TP_PROTO(struct dma_fence *fence), >

4 hours, 11 minutes

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

by Christian König

On 4/10/26 17:37, Tvrtko Ursulin wrote: > > On 10/04/2026 09:58, Christian König wrote: >> On 4/9/26 15:58, Tvrtko Ursulin wrote: >>> >>> On 31/03/2026 08:49, Boris Brezillon wrote: >>>> On Mon, 30 Mar 2026 14:36:23 +0100 >>>> Tvrtko Ursulin <tvrtko.ursulin(a)igalia.com> wrote: >>>> >>>>> Move the signalling tracepoint to before fence->ops are reset otherwise >>>>> tracepoint will dereference a null pointer. >>>> >>>> I suspect other trace points are impacted too >>>> (trace_dma_fence_destroy() is, at the very least). >>> >>> Indeed. I wonder why that did not trigger for me, while the one I fix here was an insta-crash... >> >> You need to actually enable the trace points and at least for the destroy one nobody is usually interested in that. > > Right, but I was pretty sure I was enabling perf record -e 'dma_fence:*' when I hit this. Anyway, it doesn't matter, I could be misremembering. > >>> >>> To fix trace_dma_fence_destroy I think we need a new tracepoint definition ie. move it away from the existing event class - make it just log the context and seqno. >>> >>> Anyone has a better idea? >> >> The idea of tracing without accessing fence->ops sounds valid to me. >> >> Alternatively we could call dma_fence_timeline_name() and dma_fence_driver_name() from the tracepoint as well, but that means the tracepoints now require a RCU read side lock. > > We could possibly use the helpers. I am not sure if RCU annotation would have to be casted away to keep sparse happy, but more importantly, I think it would not be safe. > > thread A thread B > > dma_fence_signal_timestamp_locked dma_fence_timeline_name > .. ops = rcu_dereference(fence->ops); > if (!dma_fence_test_signaled_flag(fence)) > test_and_set_bit > .. > RCU_INIT_POINTER(fence->ops, NULL); > return (const char __rcu *)ops->get_driver_name(fence); // OOPS! > > Apologies for long line length, it did not fit otherwise. > > Looks like we missed this. Or it is me who is missing something? See function dma_fence_driver_name() and dma_fence_timeline_name(): ops = rcu_dereference(fence->ops); if (!dma_fence_test_signaled_flag(fence)) return (const char __rcu *)ops->get_driver_name(fence); We first grab the ops pointer and then check if the fence is signaled or not. Since we first set the signaled flag and then NULL the ops pointer in the other thread we should be save here. Could only be that test_bit() is not a memory barrier, but set_bit() is so that would be a bit surprising. Alternatively I would be fine to switching testing ops for NULL instead of calling dma_fence_test_signaled_flag(). Regards, Christian. > Regards, > > Tvrtko > >>>>> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin(a)igalia.com> >>>>> Fixes: 541c8f2468b9 ("dma-buf: detach fence ops on signal v3") >>>>> Cc: Christian König <christian.koenig(a)amd.com> >>>>> Cc: Philipp Stanner <phasta(a)kernel.org> >>>>> Cc: Boris Brezillon <boris.brezillon(a)collabora.com> >>>>> Cc: linux-media(a)vger.kernel.org >>>>> Cc: linaro-mm-sig(a)lists.linaro.org >>>>> --- >>>>> drivers/dma-buf/dma-fence.c | 3 ++- >>>>> 1 file changed, 2 insertions(+), 1 deletion(-) >>>>> >>>>> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c >>>>> index 1826ba73094c..1c1eaecaf1b0 100644 >>>>> --- a/drivers/dma-buf/dma-fence.c >>>>> +++ b/drivers/dma-buf/dma-fence.c >>>>> @@ -363,6 +363,8 @@ void dma_fence_signal_timestamp_locked(struct dma_fence *fence, >>>>> &fence->flags))) >>>>> return; >>>>> + trace_dma_fence_signaled(fence); >>>>> + >>>>> /* >>>>> * When neither a release nor a wait operation is specified set the ops >>>>> * pointer to NULL to allow the fence structure to become independent >>>>> @@ -377,7 +379,6 @@ void dma_fence_signal_timestamp_locked(struct dma_fence *fence, >>>>> fence->timestamp = timestamp; >>>>> set_bit(DMA_FENCE_FLAG_TIMESTAMP_BIT, &fence->flags); >>>>> - trace_dma_fence_signaled(fence); >>>>> list_for_each_entry_safe(cur, tmp, &cb_list, node) { >>>>> INIT_LIST_HEAD(&cur->node); >>>> >>> >> >

8 hours, 51 minutes

(no subject)

by Alex Morgan

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

16 hours, 38 minutes

Enigles

by Alex Morgan

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

16 hours, 41 minutes

Enigles

by Alex Morgan

17 hours, 5 minutes

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig