When neither a release nor a wait backend ops is specified it is possible to let the dma_fence live on independently of the module who issued it.
This makes it possible to unload drivers and only wait for all their fences to signal.
v2: fix typo in comment
Signed-off-by: Christian König christian.koenig@amd.com Reviewed-by: Tvrtko Ursulin tvrtko.ursulin@igalia.com Reviewed-by: Philipp Stanner phasta@kernel.org Reviewed-by: Boris Brezillon boris.brezillon@collabora.com --- drivers/dma-buf/dma-fence.c | 16 ++++++++++++---- include/linux/dma-fence.h | 4 ++-- 2 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c index d3c4e23bf297..ae77f900c267 100644 --- a/drivers/dma-buf/dma-fence.c +++ b/drivers/dma-buf/dma-fence.c @@ -371,6 +371,14 @@ void dma_fence_signal_timestamp_locked(struct dma_fence *fence, &fence->flags))) return;
+ /* + * When neither a release nor a wait operation is specified set the ops + * pointer to NULL to allow the fence structure to become independent + * from who originally issued it. + */ + if (!fence->ops->release && !fence->ops->wait) + RCU_INIT_POINTER(fence->ops, NULL); + /* Stash the cb_list before replacing it with the timestamp */ list_replace(&fence->cb_list, &cb_list);
@@ -537,7 +545,7 @@ dma_fence_wait_timeout(struct dma_fence *fence, bool intr, signed long timeout) rcu_read_lock(); ops = rcu_dereference(fence->ops); trace_dma_fence_wait_start(fence); - if (ops->wait) { + if (ops && ops->wait) { /* * Implementing the wait ops is deprecated and not supported for * issuers of fences who need their lifetime to be independent @@ -603,7 +611,7 @@ void dma_fence_release(struct kref *kref) }
ops = rcu_dereference(fence->ops); - if (ops->release) + if (ops && ops->release) ops->release(fence); else dma_fence_free(fence); @@ -639,7 +647,7 @@ static bool __dma_fence_enable_signaling(struct dma_fence *fence)
rcu_read_lock(); ops = rcu_dereference(fence->ops); - if (!was_set && ops->enable_signaling) { + if (!was_set && ops && ops->enable_signaling) { trace_dma_fence_enable_signal(fence);
if (!ops->enable_signaling(fence)) { @@ -1025,7 +1033,7 @@ void dma_fence_set_deadline(struct dma_fence *fence, ktime_t deadline)
rcu_read_lock(); ops = rcu_dereference(fence->ops); - if (ops->set_deadline && !dma_fence_is_signaled(fence)) + if (ops && ops->set_deadline && !dma_fence_is_signaled(fence)) ops->set_deadline(fence, deadline); rcu_read_unlock(); } diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h index 9d8a4ebe8bf7..80db7ede91de 100644 --- a/include/linux/dma-fence.h +++ b/include/linux/dma-fence.h @@ -472,7 +472,7 @@ dma_fence_is_signaled_locked(struct dma_fence *fence)
rcu_read_lock(); ops = rcu_dereference(fence->ops); - if (ops->signaled && ops->signaled(fence)) { + if (ops && ops->signaled && ops->signaled(fence)) { rcu_read_unlock(); dma_fence_signal_locked(fence); return true; @@ -508,7 +508,7 @@ dma_fence_is_signaled(struct dma_fence *fence)
rcu_read_lock(); ops = rcu_dereference(fence->ops); - if (ops->signaled && ops->signaled(fence)) { + if (ops && ops->signaled && ops->signaled(fence)) { rcu_read_unlock(); dma_fence_signal(fence); return true;
Hi Christian,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next] [cannot apply to drm-i915/for-linux-next drm-i915/for-linux-next-fixes drm-xe/drm-xe-next linus/master v6.19 next-20260220] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Christian-K-nig/dma-buf-detac... base: https://gitlab.freedesktop.org/drm/misc/kernel.git drm-misc-next patch link: https://lore.kernel.org/r/20260219160822.1529-3-christian.koenig%40amd.com patch subject: [PATCH 2/8] dma-buf: detach fence ops on signal v2 config: hexagon-randconfig-r121-20260221 (https://download.01.org/0day-ci/archive/20260221/202602212322.qKZcoRK3-lkp@i...) compiler: clang version 23.0.0git (https://github.com/llvm/llvm-project e86750b29fa0ff207cd43213d66dabe565417638) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260221/202602212322.qKZcoRK3-lkp@i...)
If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot lkp@intel.com | Closes: https://lore.kernel.org/oe-kbuild-all/202602212322.qKZcoRK3-lkp@intel.com/
sparse warnings: (new ones prefixed by >>) drivers/dma-buf/dma-fence.c:1051:38: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected char const [noderef] __rcu *timeline @@ got char * @@ drivers/dma-buf/dma-fence.c:1051:38: sparse: expected char const [noderef] __rcu *timeline drivers/dma-buf/dma-fence.c:1051:38: sparse: got char * drivers/dma-buf/dma-fence.c:1052:36: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected char const [noderef] __rcu *driver @@ got char * @@ drivers/dma-buf/dma-fence.c:1052:36: sparse: expected char const [noderef] __rcu *driver drivers/dma-buf/dma-fence.c:1052:36: sparse: got char * drivers/dma-buf/dma-fence.c: note: in included file (through include/trace/trace_events.h, include/trace/define_trace.h, include/trace/events/dma_fence.h): include/trace/events/dma_fence.h:17:1: sparse: sparse: dereference of noderef expression include/trace/events/dma_fence.h:17:1: sparse: sparse: dereference of noderef expression include/trace/events/dma_fence.h:17:1: sparse: sparse: dereference of noderef expression include/trace/events/dma_fence.h:17:1: sparse: sparse: dereference of noderef expression include/trace/events/dma_fence.h:17:1: sparse: sparse: dereference of noderef expression include/trace/events/dma_fence.h:17:1: sparse: sparse: dereference of noderef expression
drivers/dma-buf/dma-fence.c:379:19: sparse: sparse: dereference of noderef expression
drivers/dma-buf/dma-fence.c:379:43: sparse: sparse: dereference of noderef expression
vim +379 drivers/dma-buf/dma-fence.c
345 346 347 /** 348 * dma_fence_signal_timestamp_locked - signal completion of a fence 349 * @fence: the fence to signal 350 * @timestamp: fence signal timestamp in kernel's CLOCK_MONOTONIC time domain 351 * 352 * Signal completion for software callbacks on a fence, this will unblock 353 * dma_fence_wait() calls and run all the callbacks added with 354 * dma_fence_add_callback(). Can be called multiple times, but since a fence 355 * can only go from the unsignaled to the signaled state and not back, it will 356 * only be effective the first time. Set the timestamp provided as the fence 357 * signal timestamp. 358 * 359 * Unlike dma_fence_signal_timestamp(), this function must be called with 360 * &dma_fence.lock held. 361 */ 362 void dma_fence_signal_timestamp_locked(struct dma_fence *fence, 363 ktime_t timestamp) 364 { 365 struct dma_fence_cb *cur, *tmp; 366 struct list_head cb_list; 367 368 lockdep_assert_held(fence->lock); 369 370 if (unlikely(test_and_set_bit(DMA_FENCE_FLAG_SIGNALED_BIT, 371 &fence->flags))) 372 return; 373 374 /* 375 * When neither a release nor a wait operation is specified set the ops 376 * pointer to NULL to allow the fence structure to become independent 377 * from who originally issued it. 378 */
379 if (!fence->ops->release && !fence->ops->wait)
380 RCU_INIT_POINTER(fence->ops, NULL); 381 382 /* Stash the cb_list before replacing it with the timestamp */ 383 list_replace(&fence->cb_list, &cb_list); 384 385 fence->timestamp = timestamp; 386 set_bit(DMA_FENCE_FLAG_TIMESTAMP_BIT, &fence->flags); 387 trace_dma_fence_signaled(fence); 388 389 list_for_each_entry_safe(cur, tmp, &cb_list, node) { 390 INIT_LIST_HEAD(&cur->node); 391 cur->func(fence, cur); 392 } 393 } 394 EXPORT_SYMBOL(dma_fence_signal_timestamp_locked); 395
linaro-mm-sig@lists.linaro.org
-
Christian König -
kernel test robot