Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

21 participants
3587 discussions

by Christian König

Hi everyone, dma_fences have ever lived under the tyranny dictated by the module lifetime of their issuer, leading to crashes should anybody still holding a reference to a dma_fence when the module of the issuer was unloaded. The basic problem is that when buffer are shared between drivers dma_fence objects can leak into external drivers and stay there even after they are signaled. The dma_resv object for example only lazy releases dma_fences. So what happens is that when the module who originally created the dma_fence unloads the dma_fence_ops function table becomes unavailable as well and so any attempt to release the fence crashes the system. Previously various approaches have been discussed, including changing the locking semantics of the dma_fence callbacks (by me) as well as using the drm scheduler as intermediate layer (by Sima) to disconnect dma_fences from their actual users, but none of them are actually solving all problems. Tvrtko did some really nice prerequisite work by protecting the returned strings of the dma_fence_ops by RCU. This way dma_fence creators where able to just wait for an RCU grace period after fence signaling before they could be save to free those data structures. Now this patch set here goes a step further and protects the whole dma_fence_ops structure by RCU, so that after the fence signals the pointer to the dma_fence_ops is set to NULL when there is no wait nor release callback given. All functionality which use the dma_fence_ops reference are put inside an RCU critical section, except for the deprecated issuer specific wait and of course the optional release callback. Additional to the RCU changes the lock protecting the dma_fence state previously had to be allocated external. This set here now changes the functionality to make that external lock optional and allows dma_fences to use an inline lock and be self contained. v4: Rebases the whole set on upstream changes, especially the cleanup from Philip in patch "drm/amdgpu: independence for the amdkfd_fence!". Adding two patches which brings the DMA-fence self tests up to date. The first selftest changes removes the mock_wait and so actually starts testing the default behavior instead of some hacky implementation in the test. This one got upstreamed independent of this set. The second drops the mock_fence as well and tests the new RCU and inline spinlock functionality. v5: Rebase on top of drm-misc-next instead of drm-tip, leave out all driver changes for now since those should go through the driver specific paths anyway. Address a few more review comments, especially some rebase mess and typos. And finally fix one more bug found by AMDs CI system. v6: Minor style changes, re-ordered patch #1, dropped the scheduler fence change for now v7: The patch adding the dma_fence_was_initialized() function was pushed upstream individually since that is really an independent cleanup. Fixed some missing i915 bits in patch "dma-buf: abstract fence locking". Please review and comment, Christian.

7 months

Best Crypto Recovery Services Providers; Top Firm to Retrieve Lost Cryptocurrency

by harrisonhall0088＠gmail.com

I want to share my experience with OPTIMISTIC HACKER GAIUS after I was scammed of my cryptocurrency. Feeling helpless, I reached out and received clear, professional guidance from the start. I explained the process, communicated consistently, and handled the situation with care. Through his expertise and persistence, my scammed crypto was successfully recovered. The support restored my confidence and eased the stress of the order. I’m grateful for the help and would recommend his services. Website: optimistichackargaius .c o m Email: support @ optimistichackargaius .c om WhatsApp: +44 737 674 0569

7 months, 1 week

HIRE AN AUTHORIZED CRYPTOCURRENCY RECOVERING HACKER / CONTACT SALVAGE ASSET RECOVERY

by gregl4368＠gmail.com

Cryptocurrency investing has always been a passion of mine but that passion quickly turned into panic when I became the victim of a fraudulent SOL trading platform. The platform promised a fifteen percent daily return which seemed like an incredible opportunity I could not miss. I was drawn in by the sleek interface, positive reviews and supposed user testimonials. Believing I had found a breakthrough I went ahead and deposited 92000 in SOL.To my horror the platform shut down the very next day. My account was wiped clean and I had no access to my funds. Just like that my entire investment vanished and I was left in financial ruin. The days that followed were some of the darkest I have ever experienced. I struggled to pay my bills, skipped meals and found myself in a deep emotional and financial pit.Feeling defeated and ashamed I turned to a close friend and confided in them. That conversation changed everything. My friend referred me to SALVAGE ASSET RECOVERY , a specialized team that deals with cryptocurrency scam recovery. I was skeptical at first. After all, I had already been scammed once and was hesitant to trust anyone again. But desperation pushed me to give it a try. SALVAGE ASSET RECOVERY impressed me. They listened carefully to my story, explained the process in clear detail and reassured me that they would do everything possible to help. Using advanced blockchain tools and digital tracing methods they were able to locate the flow of my stolen funds.Weeks later I received the news I never thought I would hear. SALVAGE ASSET RECOVERY had successfully recovered my entire 92000 in SOL. I was overwhelmed with relief and gratitude. I could finally breathe again knowing that my hard earned money had not been lost forever. If something sounds too good to be true in the crypto world it almost always is. While I still believe in the future of blockchain I now invest with much more caution and diligence.To anyone who has fallen victim to a similar scam know that all hope is not lost. Reach out to people who can truly help. SALVAGE ASSET RECOVERY gave me a second chance and for that I will always be thankful. you can use the details provided below. Whats app : +18476547096 Telegram : @Salvageasset

7 months, 1 week

HIRE AN AUTHORIZED CRYPTOCURRENCY RECOVERING HACKER / CONTACT SALVAGE ASSET RECOVERY

by gregl4368＠gmail.com

7 months, 1 week

HIRE A LICENSED BTC / CRYPTOCURRENCY RECOVERY HACKER —Reposolsa Recovery.

by amandahaynes109＠gmail.com

The team called (Reposolsa Recovery) quickly took action, filing my case and working tirelessly on my behalf. Within just four days, I received the surprising news that my 40,000 CAD had been successfully refunded and deposited back into my bank account. I was overjoyed and relieved to see the money returned, especially after the stressful experience. Thanks to (Reposolsa Recovery) professionalism and dedication, they were able to recover my funds. This experience taught me an important lesson about being cautious with online investments and the importance of seeking expert help when dealing with scams. I am truly grateful to (Reposolsa Recovery) to reach out to the recovery team here are the inform. EMAIL: reposolsarecovery(a)email.com WHATSAPP: +12092944699 WEBSITE: https://reposolsa.com Reposolsa Recovery

7 months, 1 week

[PATCH AUTOSEL 6.19-6.18] drm/amdgpu: Refactor amdgpu_gem_va_ioctl for Handling Last Fence Update and Timeline Management v4

by Sasha Levin

From: Srinivasan Shanmugam <srinivasan.shanmugam(a)amd.com> [ Upstream commit bd8150a1b3370a9f7761c5814202a3fe5a79f44f ] This commit simplifies the amdgpu_gem_va_ioctl function, key updates include: - Moved the logic for managing the last update fence directly into amdgpu_gem_va_update_vm. - Introduced checks for the timeline point to enable conditional replacement or addition of fences. v2: Addressed review comments from Christian. v3: Updated comments (Christian). v4: The previous version selected the fence too early and did not manage its reference correctly, which could lead to stale or freed fences being used. This resulted in refcount underflows and could crash when updating GPU timelines. The fence is now chosen only after the VA mapping work is completed, and its reference is taken safely. After exporting it to the VM timeline syncobj, the driver always drops its local fence reference, ensuring balanced refcounting and avoiding use-after-free on dma_fence. Crash signature: [ 205.828135] refcount_t: underflow; use-after-free. [ 205.832963] WARNING: CPU: 30 PID: 7274 at lib/refcount.c:28 refcount_warn_saturate+0xbe/0x110 ... [ 206.074014] Call Trace: [ 206.076488] <TASK> [ 206.078608] amdgpu_gem_va_ioctl+0x6ea/0x740 [amdgpu] [ 206.084040] ? __pfx_amdgpu_gem_va_ioctl+0x10/0x10 [amdgpu] [ 206.089994] drm_ioctl_kernel+0x86/0xe0 [drm] [ 206.094415] drm_ioctl+0x26e/0x520 [drm] [ 206.098424] ? __pfx_amdgpu_gem_va_ioctl+0x10/0x10 [amdgpu] [ 206.104402] amdgpu_drm_ioctl+0x4b/0x80 [amdgpu] [ 206.109387] __x64_sys_ioctl+0x96/0xe0 [ 206.113156] do_syscall_64+0x66/0x2d0 ... [ 206.553351] BUG: unable to handle page fault for address: ffffffffc0dfde90 ... [ 206.553378] RIP: 0010:dma_fence_signal_timestamp_locked+0x39/0xe0 ... [ 206.553405] Call Trace: [ 206.553409] <IRQ> [ 206.553415] ? __pfx_drm_sched_fence_free_rcu+0x10/0x10 [gpu_sched] [ 206.553424] dma_fence_signal+0x30/0x60 [ 206.553427] drm_sched_job_done.isra.0+0x123/0x150 [gpu_sched] [ 206.553434] dma_fence_signal_timestamp_locked+0x6e/0xe0 [ 206.553437] dma_fence_signal+0x30/0x60 [ 206.553441] amdgpu_fence_process+0xd8/0x150 [amdgpu] [ 206.553854] sdma_v4_0_process_trap_irq+0x97/0xb0 [amdgpu] [ 206.554353] edac_mce_amd(E) ee1004(E) [ 206.554270] amdgpu_irq_dispatch+0x150/0x230 [amdgpu] [ 206.554702] amdgpu_ih_process+0x6a/0x180 [amdgpu] [ 206.555101] amdgpu_irq_handler+0x23/0x60 [amdgpu] [ 206.555500] __handle_irq_event_percpu+0x4a/0x1c0 [ 206.555506] handle_irq_event+0x38/0x80 [ 206.555509] handle_edge_irq+0x92/0x1e0 [ 206.555513] __common_interrupt+0x3e/0xb0 [ 206.555519] common_interrupt+0x80/0xa0 [ 206.555525] </IRQ> [ 206.555527] <TASK> ... [ 206.555650] RIP: 0010:dma_fence_signal_timestamp_locked+0x39/0xe0 ... [ 206.555667] Kernel panic - not syncing: Fatal exception in interrupt Link: https://patchwork.freedesktop.org/patch/654669/ Cc: Alex Deucher <alexander.deucher(a)amd.com> Cc: Christian König <christian.koenig(a)amd.com> Suggested-by: Christian König <christian.koenig(a)amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam(a)amd.com> Reviewed-by: Christian König <christian.koenig(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- LLM Generated explanations, may be completely bogus: I now have a thorough understanding of this commit. Let me compile my complete analysis. --- ## Complete Analysis ### 1. COMMIT MESSAGE ANALYSIS The commit title says "Refactor" but the v4 description reveals this is a **critical bug fix**: > "The previous version selected the fence too early and did not manage its reference correctly, which could lead to stale or freed fences being used. This resulted in refcount underflows and could crash when updating GPU timelines." The commit includes a **concrete crash signature** showing: - `refcount_t: underflow; use-after-free` in `amdgpu_gem_va_ioctl` - `BUG: unable to handle page fault` in `dma_fence_signal_timestamp_locked` from IRQ context - `Kernel panic - not syncing: Fatal exception in interrupt` This is a **kernel panic** triggered via a userspace ioctl path (`amdgpu_gem_va_ioctl`). ### 2. CODE CHANGE ANALYSIS - THE BUG The bug is in `amdgpu_gem_update_bo_mapping()`, which was introduced by commit 70773bef4e091 ("drm/amdgpu: update userqueue BOs and PDs") in v6.16-rc1. **Bug mechanism** in the old code at lines 115-154 of the current file: ```132:154:drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c /* Find the last update fence */ switch (operation) { case AMDGPU_VA_OP_MAP: case AMDGPU_VA_OP_REPLACE: if (bo && (bo->tbo.base.resv == vm->root.bo->tbo.base.resv)) last_update = vm->last_update; else last_update = bo_va->last_pt_update; break; case AMDGPU_VA_OP_UNMAP: case AMDGPU_VA_OP_CLEAR: last_update = fence; break; default: return; } /* Add fence to timeline */ if (!point) drm_syncobj_replace_fence(syncobj, last_update); else drm_syncobj_add_point(syncobj, chain, last_update, point); ``` **Problem 1 - Missing dma_fence references**: `last_update = vm->last_update` and `last_update = bo_va->last_pt_update` read fence pointers **without taking a reference** via `dma_fence_get()`. These fences can be replaced and their references dropped by concurrent VM operations or fence signaling. The bare pointer is then passed to `drm_syncobj_replace_fence()` or `drm_syncobj_add_point()`, which attempt `dma_fence_get()` on a potentially freed fence - **use-after- free**. I verified that `vm->last_update` is replaced via `swap()` in `amdgpu_vm_sdma_commit()` (line 106-146 of `amdgpu_vm_sdma.c`), which puts the old fence. If the fence was already signaled and no other holders exist, it's freed. **Problem 2 - Fence leak**: In the calling code (lines 971-983 of 6.16.y), when `timeline_syncobj` is set and the operation is MAP/REPLACE, the `fence` (clear_freed fence) returned from `amdgpu_gem_va_update_vm()` is **never put** - it's passed to `amdgpu_gem_update_bo_mapping()` which ignores it for MAP/REPLACE operations. **The fix** properly addresses both issues: - Moves fence selection into `amdgpu_gem_va_update_vm()`, which runs immediately after the VM operations complete - Takes explicit references with `dma_fence_get()` on the selected fence - Returns the properly referenced fence to the caller - The caller **always** calls `dma_fence_put(fence)` regardless of whether a timeline syncobj is used ### 3. CLASSIFICATION This is a **use-after-free / refcount underflow bug fix** disguised as a "refactor." The crash is a kernel panic from interrupt context - one of the most severe possible outcomes. It's reachable from userspace via the `amdgpu_gem_va_ioctl` ioctl. ### 4. AFFECTED VERSIONS - Feature introduced: commit 70773bef4e091, first in **v6.16-rc1** (not in v6.15 or earlier) - Partial memleak fix: commit ad6c120f68880, also in v6.16-rc1 - **Stable trees affected**: 6.16.y, 6.17.y, 6.18.y (all confirmed to have the buggy code) - **NOT affected**: 6.12.y LTS, 6.6.y LTS, 6.1.y LTS, 5.15.y LTS (no timeline syncobj code) ### 5. SCOPE AND RISK - **Lines changed**: ~+70/-41 (net ~+30 lines, mostly restructuring) - **Files changed**: 1 (`amdgpu_gem.c`) - **Risk**: Moderate - it's a structural change, but well-contained and well-reviewed - **Review quality**: Reviewed-by Christian König (the top DRM fence/amdgpu expert), Suggested-by Christian König - **Dependency**: Uses `amdgpu_vm_is_bo_always_valid()` which exists since v6.11 - available in all affected trees - **Backport concern**: The diff may need minor adaptation for 6.16.y/6.17.y due to `va_flags` changes (6716a823d18d4 in v6.18-rc1) ### 6. USER IMPACT - **Severity**: Kernel panic (fatal exception in interrupt handler) - **Trigger**: Userspace GPU applications using the VM timeline syncobj feature (usermode queues) - **Who is affected**: AMD GPU users on 6.16+ kernels using MESA/AMDVLK with timeline synchronization ### 7. VERDICT Despite being titled "Refactor," this commit fixes: 1. A **use-after-free** on `dma_fence` objects (accessing freed memory) 2. A **refcount underflow** leading to premature fence destruction 3. A **kernel panic** in interrupt context (`dma_fence_signal_timestamp_locked`) 4. A **fence memory leak** (clear_freed fence never put when timeline is used) The fix is well-reviewed by the subsystem expert, self-contained to one file, and addresses a real crash that users hit. The affected code exists in 6.16.y, 6.17.y, and 6.18.y stable trees. **YES** drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 135 ++++++++++++++---------- 1 file changed, 82 insertions(+), 53 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c index 3e38c5db29871..c5570a9698ed2 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c @@ -112,47 +112,6 @@ amdgpu_gem_update_timeline_node(struct drm_file *filp, return 0; } -static void -amdgpu_gem_update_bo_mapping(struct drm_file *filp, - struct amdgpu_bo_va *bo_va, - uint32_t operation, - uint64_t point, - struct dma_fence *fence, - struct drm_syncobj *syncobj, - struct dma_fence_chain *chain) -{ - struct amdgpu_bo *bo = bo_va ? bo_va->base.bo : NULL; - struct amdgpu_fpriv *fpriv = filp->driver_priv; - struct amdgpu_vm *vm = &fpriv->vm; - struct dma_fence *last_update; - - if (!syncobj) - return; - - /* Find the last update fence */ - switch (operation) { - case AMDGPU_VA_OP_MAP: - case AMDGPU_VA_OP_REPLACE: - if (bo && (bo->tbo.base.resv == vm->root.bo->tbo.base.resv)) - last_update = vm->last_update; - else - last_update = bo_va->last_pt_update; - break; - case AMDGPU_VA_OP_UNMAP: - case AMDGPU_VA_OP_CLEAR: - last_update = fence; - break; - default: - return; - } - - /* Add fence to timeline */ - if (!point) - drm_syncobj_replace_fence(syncobj, last_update); - else - drm_syncobj_add_point(syncobj, chain, last_update, point); -} - static vm_fault_t amdgpu_gem_fault(struct vm_fault *vmf) { struct ttm_buffer_object *bo = vmf->vma->vm_private_data; @@ -764,16 +723,19 @@ amdgpu_gem_va_update_vm(struct amdgpu_device *adev, struct amdgpu_bo_va *bo_va, uint32_t operation) { - struct dma_fence *fence = dma_fence_get_stub(); + struct dma_fence *clear_fence = dma_fence_get_stub(); + struct dma_fence *last_update = NULL; int r; if (!amdgpu_vm_ready(vm)) - return fence; + return clear_fence; - r = amdgpu_vm_clear_freed(adev, vm, &fence); + /* First clear freed BOs and get a fence for that work, if any. */ + r = amdgpu_vm_clear_freed(adev, vm, &clear_fence); if (r) goto error; + /* For MAP/REPLACE we also need to update the BO mappings. */ if (operation == AMDGPU_VA_OP_MAP || operation == AMDGPU_VA_OP_REPLACE) { r = amdgpu_vm_bo_update(adev, bo_va, false); @@ -781,13 +743,59 @@ amdgpu_gem_va_update_vm(struct amdgpu_device *adev, goto error; } + /* Always update PDEs after we touched the mappings. */ r = amdgpu_vm_update_pdes(adev, vm, false); + if (r) + goto error; + + /* + * Decide which fence represents the "last update" for this VM/BO: + * + * - For MAP/REPLACE we want the PT update fence, which is tracked as + * either vm->last_update (for always-valid BOs) or bo_va->last_pt_update + * (for per-BO updates). + * + * - For UNMAP/CLEAR we rely on the fence returned by + * amdgpu_vm_clear_freed(), which already covers the page table work + * for the removed mappings. + */ + switch (operation) { + case AMDGPU_VA_OP_MAP: + case AMDGPU_VA_OP_REPLACE: + if (bo_va && bo_va->base.bo) { + if (amdgpu_vm_is_bo_always_valid(vm, bo_va->base.bo)) { + if (vm->last_update) + last_update = dma_fence_get(vm->last_update); + } else { + if (bo_va->last_pt_update) + last_update = dma_fence_get(bo_va->last_pt_update); + } + } + break; + case AMDGPU_VA_OP_UNMAP: + case AMDGPU_VA_OP_CLEAR: + if (clear_fence) + last_update = dma_fence_get(clear_fence); + break; + default: + break; + } error: if (r && r != -ERESTARTSYS) DRM_ERROR("Couldn't update BO_VA (%d)\n", r); - return fence; + /* + * If we managed to pick a more specific last-update fence, prefer it + * over the generic clear_fence and drop the extra reference to the + * latter. + */ + if (last_update) { + dma_fence_put(clear_fence); + return last_update; + } + + return clear_fence; } int amdgpu_gem_va_ioctl(struct drm_device *dev, void *data, @@ -813,6 +821,7 @@ int amdgpu_gem_va_ioctl(struct drm_device *dev, void *data, uint64_t vm_size; int r = 0; + /* Validate virtual address range against reserved regions. */ if (args->va_address < AMDGPU_VA_RESERVED_BOTTOM) { dev_dbg(dev->dev, "va_address 0x%llx is in reserved area 0x%llx\n", @@ -846,6 +855,7 @@ int amdgpu_gem_va_ioctl(struct drm_device *dev, void *data, return -EINVAL; } + /* Validate operation type. */ switch (args->operation) { case AMDGPU_VA_OP_MAP: case AMDGPU_VA_OP_UNMAP: @@ -869,6 +879,7 @@ int amdgpu_gem_va_ioctl(struct drm_device *dev, void *data, abo = NULL; } + /* Add input syncobj fences (if any) for synchronization. */ r = amdgpu_gem_add_input_fence(filp, args->input_fence_syncobj_handles, args->num_syncobj_handles); @@ -891,6 +902,7 @@ int amdgpu_gem_va_ioctl(struct drm_device *dev, void *data, goto error; } + /* Resolve the BO-VA mapping for this VM/BO combination. */ if (abo) { bo_va = amdgpu_vm_bo_find(&fpriv->vm, abo); if (!bo_va) { @@ -903,6 +915,11 @@ int amdgpu_gem_va_ioctl(struct drm_device *dev, void *data, bo_va = NULL; } + /* + * Prepare the timeline syncobj node if the user requested a VM + * timeline update. This only allocates/looks up the syncobj and + * chain node; the actual fence is attached later. + */ r = amdgpu_gem_update_timeline_node(filp, args->vm_timeline_syncobj_out, args->vm_timeline_point, @@ -934,18 +951,30 @@ int amdgpu_gem_va_ioctl(struct drm_device *dev, void *data, default: break; } + + /* + * Once the VA operation is done, update the VM and obtain the fence + * that represents the last relevant update for this mapping. This + * fence can then be exported to the user-visible VM timeline. + */ if (!r && !(args->flags & AMDGPU_VM_DELAY_UPDATE) && !adev->debug_vm) { fence = amdgpu_gem_va_update_vm(adev, &fpriv->vm, bo_va, args->operation); - if (timeline_syncobj) - amdgpu_gem_update_bo_mapping(filp, bo_va, - args->operation, - args->vm_timeline_point, - fence, timeline_syncobj, - timeline_chain); - else - dma_fence_put(fence); + if (timeline_syncobj && fence) { + if (!args->vm_timeline_point) { + /* Replace the existing fence when no point is given. */ + drm_syncobj_replace_fence(timeline_syncobj, + fence); + } else { + /* Attach the last-update fence at a specific point. */ + drm_syncobj_add_point(timeline_syncobj, + timeline_chain, + fence, + args->vm_timeline_point); + } + } + dma_fence_put(fence); } -- 2.51.0

7 months, 1 week

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

by Jiri Pirko

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

7 months, 1 week

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

by wsuttles6＠gmail.com

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

7 months, 1 week

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

by Christian König

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

7 months, 2 weeks

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

by asml.silence＠gmail.com

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

7 months, 2 weeks

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig