Linaro-mm-sig April 2026

linaro-mm-sig@lists.linaro.org

91 participants
216 discussions

[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>

1 month, 3 weeks

[PATCH 0/5] Replace the dmabuf custom test framework with kunit

by Jason Gunthorpe

Using kunit to write tests for new work on dmabuf is coming up: https://lore.kernel.org/all/26-v1-b5cab63049c0+191af-dmabuf_map_type_jgg@nv… Replace the custom test framework with kunit to avoid maintaining two concurrent test frameworks. The conversion minimizes code changes and uses simple pattern-oriented reworks to reduce the chance of breaking any tests. Aside from adding the kunit_test_suite() boilerplate, the conversion follows a number of patterns: Test failures without cleanup. For example: if (!ptr) return -ENOMEM; Becomes: KUNIT_ASSERT_NOT_NULL(test, ptr); In kunit ASSERT longjumps out of the test. Check for error, fail and cleanup: if (err) { pr_err("msg\n"); goto cleanup; } Becomes: if (err) { KUNIT_FAIL(test, "msg"); goto cleanup; } Preserve the existing failure messages and cleanup code. Cases where the test returns err but prints no message: if (err) goto cleanup; Becomes: if (err) { KUNIT_FAIL(test, "msg"); goto cleanup; } Use KUNIT_FAIL to retain the 'cleanup on err' behavior. Overall, the conversion is straightforward. The result can be run with kunit.py: $ tools/testing/kunit/kunit.py run --build_dir build_kunit_x86_64 --arch x86_64 --kunitconfig ./drivers/dma-buf/.kunitconfig [20:37:23] Configuring KUnit Kernel ... [20:37:23] Building KUnit Kernel ... Populating config with: $ make ARCH=x86_64 O=build_kunit_x86_64 olddefconfig Building with: $ make all compile_commands.json scripts_gdb ARCH=x86_64 O=build_kunit_x86_64 --jobs=20 [20:37:29] Starting KUnit Kernel (1/1)... [20:37:29] ============================================================ Running tests with: $ qemu-system-x86_64 -nodefaults -m 1024 -kernel build_kunit_x86_64/arch/x86/boot/bzImage -append 'kunit.enable=1 console=ttyS0 kunit_shutdown=reboot' -no-reboot -nographic -accel kvm -accel hvf -accel tcg -serial stdio -bios qboot.rom [20:37:30] ================ dma-buf-resv (5 subtests) ================= [20:37:30] [PASSED] test_sanitycheck [20:37:30] ===================== test_signaling ====================== [20:37:30] [PASSED] kernel [20:37:30] [PASSED] write [20:37:30] [PASSED] read [20:37:30] [PASSED] bookkeep [20:37:30] ================= [PASSED] test_signaling ================== ... [20:37:35] Testing complete. Ran 50 tests: passed: 49, skipped: 1 [20:37:35] Elapsed time: 12.635s total, 0.001s configuring, 6.551s building, 6.017s running One test that requires two CPUs is skipped since the default VM has a single CPU and cannot run the test. All other usual ways to run kunit work as well, and all tests are placed in a module to provide more options for how they are run. AI was used to do the large scale semantic search and replaces described above, then everything was hand checked. AI also deduced the issue with test_race_signal_callback() in a couple of seconds from the kunit crash (!!), again was hand checked though I am not so familiar with this test to be fully certain this is the best answer. Jason Gunthorpe (5): dma-buf: Change st-dma-resv.c to use kunit dma-buf: Change st-dma-fence.c to use kunit dma-buf: Change st-dma-fence-unwrap.c to use kunit dma-buf: Change st-dma-fence-chain.c to use kunit dma-buf: Remove the old selftest drivers/dma-buf/.kunitconfig | 2 + drivers/dma-buf/Kconfig | 11 +- drivers/dma-buf/Makefile | 5 +- drivers/dma-buf/selftest.c | 167 --------------- drivers/dma-buf/selftest.h | 30 --- drivers/dma-buf/selftests.h | 16 -- drivers/dma-buf/st-dma-fence-chain.c | 217 +++++++++---------- drivers/dma-buf/st-dma-fence-unwrap.c | 290 +++++++++++--------------- drivers/dma-buf/st-dma-fence.c | 200 ++++++++---------- drivers/dma-buf/st-dma-resv.c | 145 +++++++------ drivers/gpu/drm/i915/Kconfig.debug | 2 +- 11 files changed, 394 insertions(+), 691 deletions(-) create mode 100644 drivers/dma-buf/.kunitconfig delete mode 100644 drivers/dma-buf/selftest.c delete mode 100644 drivers/dma-buf/selftest.h delete mode 100644 drivers/dma-buf/selftests.h base-commit: 41dae5ac5e157b0bb260f381eb3df2f4a4610205 -- 2.43.0

1 month, 3 weeks

[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

1 month, 3 weeks

Enigles

by Alex Morgan

How Can I Recover My Lost Cryptocurrency, Hire Ghost Mystery Recovery Hacker Ghost Mystery Recovery Hacker delivered an excellent experience when I needed help recovering something I thought was permanently lost. From the start, their communication was clear, professional, and reassuring, which immediately made me feel more confident about the process. They took the time to understand my situation and explained each step in a way that was honest and easy to follow. What stood out most was their consistency and dedication. I was kept informed throughout, and they remained patient and responsive whenever I had questions. Their expertise was evident in the way they handled everything carefully and efficiently, without creating false expectations.The outcome exceeded what I had hoped for. They were able to successfully resolve my issue, which brought me a great sense of relief. It’s not often you come across a service that combines professionalism, transparency, and results so well. I would strongly recommend Ghost Mystery Recovery Hacker to anyone looking for reliable recovery support. Their commitment to helping clients and delivering real results truly sets them apart. Email address: support@ ghostmysteryrecovery. c om WhatsApp on (+44) 7480 061765 Website; ghostmysteryrecovery. c om

1 month, 3 weeks

(no subject)

by Alex Morgan

1 month, 3 weeks

Enigles

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

1 month, 3 weeks

Enigles

by Alex Morgan

1 month, 3 weeks

[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

1 month, 3 weeks

[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

1 month, 3 weeks

[PATCH] dma-buf: fix stale @lock references in struct dma_buf documentation

by Xiang Gao

From: Xiang Gao <gaoxiang17(a)xiaomi.com> The kernel-doc comments for vmapping_counter and vmap_ptr in struct dma_buf reference "@lock" as the protecting lock, but struct dma_buf no longer has a "lock" member. The mutex was removed in favor of using the dma_resv lock exclusively. The implementation correctly uses dma_resv_assert_held(dmabuf->resv) in dma_buf_vmap() and dma_buf_vunmap(), so update the documentation to reference @resv instead. Signed-off-by: gaoxiang17 <gaoxiang17(a)xiaomi.com> --- include/linux/dma-buf.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h index 133b9e637b55..ef6d93fd7a2c 100644 --- a/include/linux/dma-buf.h +++ b/include/linux/dma-buf.h @@ -322,13 +322,13 @@ struct dma_buf { * @vmapping_counter: * * Used internally to refcnt the vmaps returned by dma_buf_vmap(). - * Protected by @lock. + * Protected by @resv. */ unsigned vmapping_counter; /** * @vmap_ptr: - * The current vmap ptr if @vmapping_counter > 0. Protected by @lock. + * The current vmap ptr if @vmapping_counter > 0. Protected by @resv. */ struct iosys_map vmap_ptr; -- 2.34.1

1 month, 3 weeks

← Newer
1
...
12
13
14
15
16
17
18
...
22
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig April 2026