Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

17 participants
3642 discussions

How Funds Reclaimer Company Investigates Pig Butchering Fraud

by petersongreg565＠gmail.com

I am writing to express my deepest gratitude to FUNDS RECLAIMER COMPANY for their invaluable assistance in recovering my Bitcoin, which was unfortunately lost to a scammer. The expertise and professionalism displayed by their team were instrumental in retrieving my stolen funds, and I am truly thankful for their support throughout this ordeal. After falling victim to a sophisticated scam, I thought all hope was lost, and my Bitcoin was gone for good. However, I decided to reach out to FUNDS RECLAIMER COMPANY, and their team promptly responded with a clear plan of action to recover my stolen funds. Their dedication and expertise in navigating the complexities of cryptocurrency transactions were impressive, and they worked tirelessly to track down the scammer and retrieve my Bitcoin. The entire process, from initial consultation to the final recovery of my funds, was handled with utmost care and transparency. The team at FUNDS RECLAIMER COMPANY kept me informed every step of the way, providing regular updates on the progress of the recovery efforts. Their commitment to customer satisfaction was evident in the way they handled my case, and I was constantly reassured that my case was being treated with the utmost importance. I am thrilled to have my Bitcoin back, and I attribute this success entirely to the exceptional work of FUNDS RECLAIMER COMPANY. Their knowledge and experience in dealing with cryptocurrency scams are unparalleled, and I would highly recommend their services to anyone who has fallen victim to similar situations. The company's expertise and professionalism are a beacon of hope for those who have lost their funds to scammers, and I am living proof of their ability to deliver results. In conclusion, I would like to extend my sincerest appreciation to FUNDS RECLAIMER COMPANY for their outstanding service and support. Their expertise and dedication have given me a second chance to recover my lost Bitcoin, and I will be forever grateful for their help. If you or someone you know has been a victim of a cryptocurrency scam, I strongly recommend reaching out to FUNDS RECLAIMER COMPANY for assistance. They are truly the experts in recovering lost funds, and their professionalism and transparency make them a trusted partner in the fight against scammers. Info Below: Website: https//:funds-reclaimercompany.org Email: fundsreclaimer(a)consultant.com

6 months

[PATCH 0/8] drm/imagination: Job submission fixes and cleanup

by Alessio Belle

The first two commits fix rare bugs and should be backported to stable branches. The rest is an attempt to cleanup and document the code to make it a bit easier to understand. Signed-off-by: Alessio Belle <alessio.belle(a)imgtec.com> --- Alessio Belle (8): drm/imagination: Count paired job fence as dependency in prepare_job() drm/imagination: Fit paired fragment job in the correct CCCB drm/imagination: Skip check on paired job fence during job submission drm/imagination: Rename pvr_queue_fence_is_ufo_backed() to reflect usage drm/imagination: Rename fence returned by pvr_queue_job_arm() drm/imagination: Move repeated job fence check to its own function drm/imagination: Update check to skip prepare_job() for fragment jobs drm/imagination: Minor improvements to job submission code documentation drivers/gpu/drm/imagination/pvr_job.c | 8 +- drivers/gpu/drm/imagination/pvr_queue.c | 154 +++++++++++++-------- drivers/gpu/drm/imagination/pvr_queue.h | 2 +- .../gpu/drm/imagination/pvr_rogue_fwif_shared.h | 10 +- drivers/gpu/drm/imagination/pvr_sync.c | 8 +- drivers/gpu/drm/imagination/pvr_sync.h | 2 +- 6 files changed, 110 insertions(+), 74 deletions(-) --- base-commit: 3bce3fdd1ff2ba242f76ab66659fff27207299f1 change-id: 20260330-job-submission-fixes-cleanup-83e01196c3e9 Best regards, -- Alessio Belle <alessio.belle(a)imgtec.com>

6 months

[PATCH 15901/15901] drm/vmwgfx: fix NULL pointer dereference in vmw_validation_bo_fence()

by popov.nkv＠gmail.com

From: Vladimir Popov <popov.nkv(a)gmail.com> If vmw_execbuf_fence_commands() call fails in vmw_kms_helper_validation_finish(), it sets *p_fence = NULL. If ctx->bo_list is not empty, the caller, vmw_kms_helper_validation_finish(), passes the fence through a chain of functions to dma_fence_is_array(), which causes a NULL pointer dereference in dma_fence_is_array(): vmw_kms_helper_validation_finish() // pass NULL fence vmw_validation_done() vmw_validation_bo_fence() ttm_eu_fence_buffer_objects() // pass NULL fence dma_resv_add_fence() dma_fence_is_container() dma_fence_is_array() // NULL deref Fix this by adding a NULL check in vmw_validation_bo_fence(): if the fence is NULL, fall back to ttm_eu_backoff_reservation()to safely release the buffer object reservations without attempting to add a NULL fence to dma_resv. This is safe because when fence is NULL, vmw_fallback_wait() has already been called inside vmw_execbuf_fence_commands() to synchronize the GPU. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 038ecc503236 ("drm/vmwgfx: Add a validation module v2") Cc: stable(a)vger.kernel.org Signed-off-by: Vladimir Popov <popov.nkv(a)gmail.com> --- drivers/gpu/drm/vmwgfx/vmwgfx_validation.h | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_validation.h b/drivers/gpu/drm/vmwgfx/vmwgfx_validation.h index 353d837907d8..fc04555ca505 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_validation.h +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_validation.h @@ -127,16 +127,23 @@ vmw_validation_bo_reserve(struct vmw_validation_context *ctx, * vmw_validation_bo_fence - Unreserve and fence buffer objects registered * with a validation context * @ctx: The validation context + * @fence: Fence with which to fence all buffer objects taking part in the + * command submission. * * This function unreserves the buffer objects previously reserved using - * vmw_validation_bo_reserve, and fences them with a fence object. + * vmw_validation_bo_reserve, and fences them with a fence object if the + * given fence object is not NULL. */ static inline void vmw_validation_bo_fence(struct vmw_validation_context *ctx, struct vmw_fence_obj *fence) { - ttm_eu_fence_buffer_objects(&ctx->ticket, &ctx->bo_list, - (void *) fence); + /* fence is able to be NULL if vmw_execbuf_fence_commands() fails */ + if (fence) + ttm_eu_fence_buffer_objects(&ctx->ticket, &ctx->bo_list, + (void *)fence); + else + ttm_eu_backoff_reservation(&ctx->ticket, &ctx->bo_list); } /** -- 2.43.0

6 months

[PATCH 1/2] dma-fence: Silence sparse warning in dma_fence_describe

by Tvrtko Ursulin

Sparse complains about assigning a string to a __rcu annotated local variable: drivers/dma-buf/dma-fence.c:1040:38: warning: incorrect type in initializer (different address spaces) drivers/dma-buf/dma-fence.c:1040:38: expected char const [noderef] __rcu *timeline drivers/dma-buf/dma-fence.c:1040:38: got char * drivers/dma-buf/dma-fence.c:1041:36: warning: incorrect type in initializer (different address spaces) drivers/dma-buf/dma-fence.c:1041:36: expected char const [noderef] __rcu *driver drivers/dma-buf/dma-fence.c:1041:36: got char * It is harmless but lets silence it. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin(a)igalia.com> Fixes: ac364014fd81 ("dma-buf: cleanup dma_fence_describe v3") Cc: Christian König <christian.koenig(a)amd.com> Cc: linux-media(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org Cc: linaro-mm-sig(a)lists.linaro.org --- drivers/dma-buf/dma-fence.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c index 1826ba73094c..a2aa82f4eedd 100644 --- a/drivers/dma-buf/dma-fence.c +++ b/drivers/dma-buf/dma-fence.c @@ -1037,8 +1037,8 @@ EXPORT_SYMBOL(dma_fence_set_deadline); */ void dma_fence_describe(struct dma_fence *fence, struct seq_file *seq) { - const char __rcu *timeline = ""; - const char __rcu *driver = ""; + const char __rcu *timeline = (const char __rcu *)""; + const char __rcu *driver = (const char __rcu *)""; const char *signaled = ""; rcu_read_lock(); -- 2.52.0

6 months

[PATCH 1/2] dma-fence: Silence sparse warning in dma_fence_describe

by Tvrtko Ursulin

Sparse complains about assigning a string to a __rcu annotated local variable: drivers/dma-buf/dma-fence.c:1040:38: warning: incorrect type in initializer (different address spaces) drivers/dma-buf/dma-fence.c:1040:38: expected char const [noderef] __rcu *timeline drivers/dma-buf/dma-fence.c:1040:38: got char * drivers/dma-buf/dma-fence.c:1041:36: warning: incorrect type in initializer (different address spaces) drivers/dma-buf/dma-fence.c:1041:36: expected char const [noderef] __rcu *driver drivers/dma-buf/dma-fence.c:1041:36: got char * It is harmless but lets silence it. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin(a)igalia.com> Fixes: ac364014fd81 ("dma-buf: cleanup dma_fence_describe v3") Cc: Christian König <christian.koenig(a)amd.com> Cc: linux-media(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org Cc: linaro-mm-sig(a)lists.linaro.org Reviewed-by: Christian König <christian.koenig(a)amd.com> --- drivers/dma-buf/dma-fence.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c index 1826ba73094c..a2aa82f4eedd 100644 --- a/drivers/dma-buf/dma-fence.c +++ b/drivers/dma-buf/dma-fence.c @@ -1037,8 +1037,8 @@ EXPORT_SYMBOL(dma_fence_set_deadline); */ void dma_fence_describe(struct dma_fence *fence, struct seq_file *seq) { - const char __rcu *timeline = ""; - const char __rcu *driver = ""; + const char __rcu *timeline = (const char __rcu *)""; + const char __rcu *driver = (const char __rcu *)""; const char *signaled = ""; rcu_read_lock(); -- 2.52.0

6 months

[PATCH] mm/vmalloc: map contiguous pages in batches for vmap() whenever possible

by Barry Song

From: Barry Song <v-songbaohua(a)oppo.com> In many cases, the pages passed to vmap() may include high-order pages allocated with __GFP_COMP flags. For example, the systemheap often allocates pages in descending order: order 8, then 4, then 0. Currently, vmap() iterates over every page individually—even pages inside a high-order block are handled one by one. This patch detects high-order pages and maps them as a single contiguous block whenever possible. An alternative would be to implement a new API, vmap_sg(), but that change seems to be large in scope. When vmapping a 128MB dma-buf using the systemheap, this patch makes system_heap_do_vmap() roughly 17× faster. W/ patch: [ 10.404769] system_heap_do_vmap took 2494000 ns [ 12.525921] system_heap_do_vmap took 2467008 ns [ 14.517348] system_heap_do_vmap took 2471008 ns [ 16.593406] system_heap_do_vmap took 2444000 ns [ 19.501341] system_heap_do_vmap took 2489008 ns W/o patch: [ 7.413756] system_heap_do_vmap took 42626000 ns [ 9.425610] system_heap_do_vmap took 42500992 ns [ 11.810898] system_heap_do_vmap took 42215008 ns [ 14.336790] system_heap_do_vmap took 42134992 ns [ 16.373890] system_heap_do_vmap took 42750000 ns Cc: David Hildenbrand <david(a)kernel.org> Cc: Uladzislau Rezki <urezki(a)gmail.com> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: John Stultz <jstultz(a)google.com> Cc: Maxime Ripard <mripard(a)kernel.org> Tested-by: Tangquan Zheng <zhengtangquan(a)oppo.com> Signed-off-by: Barry Song <v-songbaohua(a)oppo.com> --- * diff with rfc: Many code refinements based on David's suggestions, thanks! Refine comment and changelog according to Uladzislau, thanks! rfc link: https://lore.kernel.org/linux-mm/20251122090343.81243-1-21cnbao@gmail.com/ mm/vmalloc.c | 45 +++++++++++++++++++++++++++++++++++++++------ 1 file changed, 39 insertions(+), 6 deletions(-) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 41dd01e8430c..8d577767a9e5 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -642,6 +642,29 @@ static int vmap_small_pages_range_noflush(unsigned long addr, unsigned long end, return err; } +static inline int get_vmap_batch_order(struct page **pages, + unsigned int stride, unsigned int max_steps, unsigned int idx) +{ + int nr_pages = 1; + + /* + * Currently, batching is only supported in vmap_pages_range + * when page_shift == PAGE_SHIFT. + */ + if (stride != 1) + return 0; + + nr_pages = compound_nr(pages[idx]); + if (nr_pages == 1) + return 0; + if (max_steps < nr_pages) + return 0; + + if (num_pages_contiguous(&pages[idx], nr_pages) == nr_pages) + return compound_order(pages[idx]); + return 0; +} + /* * vmap_pages_range_noflush is similar to vmap_pages_range, but does not * flush caches. @@ -655,23 +678,33 @@ int __vmap_pages_range_noflush(unsigned long addr, unsigned long end, pgprot_t prot, struct page **pages, unsigned int page_shift) { unsigned int i, nr = (end - addr) >> PAGE_SHIFT; + unsigned int stride; WARN_ON(page_shift < PAGE_SHIFT); + /* + * For vmap(), users may allocate pages from high orders down to + * order 0, while always using PAGE_SHIFT as the page_shift. + * We first check whether the initial page is a compound page. If so, + * there may be an opportunity to batch multiple pages together. + */ if (!IS_ENABLED(CONFIG_HAVE_ARCH_HUGE_VMALLOC) || - page_shift == PAGE_SHIFT) + (page_shift == PAGE_SHIFT && !PageCompound(pages[0]))) return vmap_small_pages_range_noflush(addr, end, prot, pages); - for (i = 0; i < nr; i += 1U << (page_shift - PAGE_SHIFT)) { - int err; + stride = 1U << (page_shift - PAGE_SHIFT); + for (i = 0; i < nr; ) { + int err, order; - err = vmap_range_noflush(addr, addr + (1UL << page_shift), + order = get_vmap_batch_order(pages, stride, nr - i, i); + err = vmap_range_noflush(addr, addr + (1UL << (page_shift + order)), page_to_phys(pages[i]), prot, - page_shift); + page_shift + order); if (err) return err; - addr += 1UL << page_shift; + addr += 1UL << (page_shift + order); + i += 1U << (order + page_shift - PAGE_SHIFT); } return 0; -- 2.39.3 (Apple Git-146)

6 months

Understanding Blockchain Forensics:

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.

6 months

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

by Maíra Canal

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. 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. */ 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, -- 2.53.0

6 months

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

by Christian König

Dropping the last reference to the DMA-buf and then accessing the name for tracing can't work correctly. Only compile tested! Signed-off-by: Christian König <christian.koenig(a)amd.com> Fixed: 281a22631423 ("dma-buf: add some tracepoints to debug.") --- drivers/dma-buf/dma-buf.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 11711874a325..3a9d5113b98c 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -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); } EXPORT_SYMBOL_NS_GPL(dma_buf_put, "DMA_BUF"); -- 2.43.0

6 months

[PATCH 1/3] dma-fence: Silce sparse warning in dma_fence_describe

by Tvrtko Ursulin

6 months, 1 week

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig