Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

25 participants
6165 discussions

[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 day, 7 hours

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 day, 21 hours

(no subject)

by Alex Morgan

1 day, 21 hours

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

2 days, 8 hours

Enigles

by Alex Morgan

2 days, 8 hours

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

by Christian König

On 4/15/26 10:33, Tvrtko Ursulin wrote: > > On 15/04/2026 09:13, Christian König wrote: >> On 4/15/26 09:58, Tvrtko Ursulin wrote: >>> >>> On 14/04/2026 19:30, Christian König wrote: >>>> On 4/14/26 17:49, Tvrtko Ursulin wrote: >>>>> Trace_dma_fence_signaled, trace_dma_fence_wait_end and >>>>> trace_dma_fence_destroy can all currently dereference a null fence->ops >>>>> pointer after it has been reset on fence signalling. >>>>> >>>>> Lets use the safe string getters for most tracepoints to avoid this class >>>>> of a problem, while for the signal tracepoint we move it to before ops are >>>>> cleared to avoid losing the driver and timeline name information. Apart >>>>> from moving it we also need to add a new tracepoint class to bypass the >>>>> safe name getters since the signaled bit is already set. >>>>> >>>>> For dma_fence_init we also need to use the new tracepoint class since the >>>>> rcu read lock is not held there, and we can do the same for the enable >>>>> signaling since there we are certain the fence cannot be signaled while >>>>> we are holding the lock and have even validated the fence->ops. >>>>> >>>>> 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 | 33 ++++++++++++++++++++++++++++---- >>>>> 2 files changed, 31 insertions(+), 5 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); >>>> >>>> I think this part here should be a separate patch. >>> >>> I had that in https://lore.kernel.org/dri-devel/20260330133623.17704-1-tvrtko.ursulin@iga… but the discussion fizzled out before an rb. >>> >>>> >>>>> 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..9e0cb9ce2388 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)) >>>>> + __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) >>>>> +); >>>>> + >>>> >>>> Mhm, I'm strongly in favor to just use this approach for all trace points. >>>> >>>> The minimal extra overhead shouldn't really matter at all. >>> >>> Yeah, I am a bit on the fence. It would required a bit of an ugly rcu_read_lock around trace_dma_fence_signal_init >> >> I think as long as we only grab the RCU read side lock when the tracepoint is actually enabled then that shouldn't matter. >> >> I do remember patches flying by which optimized this use case for the whole trace subsystem but didn't took a closer look how to do that now. >> >>> and trace_dma_fence_signaled would lose the driver/timeline info _unless_ name helpers would also be changed to look at fence->ops instead of "is signaled". Those have no memory barriers so not sure I want to think about racyness and how to solve it. >> >> Mhm, that is a bit more problematic. >> >> ops is only set to NULL when neither free nor wait is specified, so checking is signaled is still the right thing to do for drivers which uses those callbacks but still want to have the RCU protection of the returned strings. > > Hm yes, that too. > > >> Ok, feel free to go ahead with this approach for now but please add a /* TODO: clean that up when most drivers switched to independent fences */. > > Thank you, I've sent an updated version with a comment to this effect placed to the event class definition. I put your r-b so please double check if you are happy with that version. Yeah works for me, feel free to push to drm-misc-next. Thanks, Christian. > > Regards, > > Tvrtko >>>>> /* >>>>> * 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), >>>>> @@ -46,7 +71,7 @@ DEFINE_EVENT(dma_fence, dma_fence_emit, >>>>> TP_ARGS(fence) >>>>> ); >>>>> -DEFINE_EVENT(dma_fence, dma_fence_init, >>>>> +DEFINE_EVENT(dma_fence_ops, dma_fence_init, >>>>> TP_PROTO(struct dma_fence *fence), >>>>> @@ -60,14 +85,14 @@ DEFINE_EVENT(dma_fence, dma_fence_destroy, >>>>> TP_ARGS(fence) >>>>> ); >>>>> -DEFINE_EVENT(dma_fence, dma_fence_enable_signal, >>>>> +DEFINE_EVENT(dma_fence_ops, dma_fence_enable_signal, >>>>> TP_PROTO(struct dma_fence *fence), >>>>> TP_ARGS(fence) >>>>> ); >>>>> -DEFINE_EVENT(dma_fence, dma_fence_signaled, >>>>> +DEFINE_EVENT(dma_fence_ops, dma_fence_signaled, >>>>> TP_PROTO(struct dma_fence *fence), >>>>> >>>> >>> >> >

2 days, 10 hours

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

by Christian König

On 4/15/26 09:58, Tvrtko Ursulin wrote: > > On 14/04/2026 19:30, Christian König wrote: >> On 4/14/26 17:49, Tvrtko Ursulin wrote: >>> Trace_dma_fence_signaled, trace_dma_fence_wait_end and >>> trace_dma_fence_destroy can all currently dereference a null fence->ops >>> pointer after it has been reset on fence signalling. >>> >>> Lets use the safe string getters for most tracepoints to avoid this class >>> of a problem, while for the signal tracepoint we move it to before ops are >>> cleared to avoid losing the driver and timeline name information. Apart >>> from moving it we also need to add a new tracepoint class to bypass the >>> safe name getters since the signaled bit is already set. >>> >>> For dma_fence_init we also need to use the new tracepoint class since the >>> rcu read lock is not held there, and we can do the same for the enable >>> signaling since there we are certain the fence cannot be signaled while >>> we are holding the lock and have even validated the fence->ops. >>> >>> 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 | 33 ++++++++++++++++++++++++++++---- >>> 2 files changed, 31 insertions(+), 5 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); >> >> I think this part here should be a separate patch. > > I had that in https://lore.kernel.org/dri-devel/20260330133623.17704-1-tvrtko.ursulin@iga… but the discussion fizzled out before an rb. > >> >>> 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..9e0cb9ce2388 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)) >>> + __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) >>> +); >>> + >> >> Mhm, I'm strongly in favor to just use this approach for all trace points. >> >> The minimal extra overhead shouldn't really matter at all. > > Yeah, I am a bit on the fence. It would required a bit of an ugly rcu_read_lock around trace_dma_fence_signal_init I think as long as we only grab the RCU read side lock when the tracepoint is actually enabled then that shouldn't matter. I do remember patches flying by which optimized this use case for the whole trace subsystem but didn't took a closer look how to do that now. > and trace_dma_fence_signaled would lose the driver/timeline info _unless_ name helpers would also be changed to look at fence->ops instead of "is signaled". Those have no memory barriers so not sure I want to think about racyness and how to solve it. Mhm, that is a bit more problematic. ops is only set to NULL when neither free nor wait is specified, so checking is signaled is still the right thing to do for drivers which uses those callbacks but still want to have the RCU protection of the returned strings. Ok, feel free to go ahead with this approach for now but please add a /* TODO: clean that up when most drivers switched to independent fences */. Thanks, Christian. > > Regards, > > Tvrtko > >> >> Regards, >> Christian. >> >>> /* >>> * 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), >>> @@ -46,7 +71,7 @@ DEFINE_EVENT(dma_fence, dma_fence_emit, >>> TP_ARGS(fence) >>> ); >>> -DEFINE_EVENT(dma_fence, dma_fence_init, >>> +DEFINE_EVENT(dma_fence_ops, dma_fence_init, >>> TP_PROTO(struct dma_fence *fence), >>> @@ -60,14 +85,14 @@ DEFINE_EVENT(dma_fence, dma_fence_destroy, >>> TP_ARGS(fence) >>> ); >>> -DEFINE_EVENT(dma_fence, dma_fence_enable_signal, >>> +DEFINE_EVENT(dma_fence_ops, dma_fence_enable_signal, >>> TP_PROTO(struct dma_fence *fence), >>> TP_ARGS(fence) >>> ); >>> -DEFINE_EVENT(dma_fence, dma_fence_signaled, >>> +DEFINE_EVENT(dma_fence_ops, dma_fence_signaled, >>> TP_PROTO(struct dma_fence *fence), >>> >> >

2 days, 11 hours

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

by Christian König

On 4/15/26 03:08, Zack Rusin wrote: > On Tue, Apr 14, 2026 at 9:25 AM Christian König > <christian.koenig(a)amd.com> wrote: >> >> On 4/14/26 12:55, popov.nkv(a)gmail.com wrote: >>> 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 >> >> Well good catch, but that is clearly not the right fix. >> >> I'm not an expert for the vmwgfx code but in case of an error vmw_validation_revert() should be called an not vmw_kms_helper_validation_finish(). > > To me the patch looks correct. This path is explicitly for submission > failure and does BO backoff plus vmw_validation_res_unreserve(ctx, > true). The backoff=true branch skips committing dirty-state / > backup-MOB changes, which is only correct if commands were not > committed. Here the commands have already been submitted; only fence > creation failed. So I think unlocking BO reservations without > attaching a fence, then letting vmw_validation_done() keep taking the > success path for resources is correct. Ah! I would just avoid adding more TTM exec code dependencies. We also have the always signaled stub fence for such use cases. How about that change here: diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c index e1f18020170a..8dcb8cd19e29 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c @@ -3843,7 +3843,7 @@ int vmw_execbuf_fence_commands(struct drm_file *file_priv, if (unlikely(ret != 0 && !synced)) { (void) vmw_fallback_wait(dev_priv, false, false, sequence, false, VMW_FENCE_WAIT_TIMEOUT); - *p_fence = NULL; + *p_fence = dma_fence_get_stub(); } return ret; > iirc the same helper is used by execbuf, and the shared-helper fix > correctly covers both paths so this is probably not only a kms issue. > > Untangling this code would make sense because it's confusing, but > that's not something I'd expect Vladimir to do :) Yeah fence memory allocation should definitely be move before submitting the commands. But that is clearly more work. Thanks, Christian. > > z

2 days, 11 hours

Enigles

by Alex Morgan

2 days, 22 hours

Enigles

by Alex Morgan

2 days, 22 hours

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig