All of lore.kernel.org
 help / color / mirror / Atom feed
From: Philipp Stanner <phasta@mailbox.org>
To: phasta@kernel.org, "Jiri Slaby" <jirislaby@kernel.org>,
	"Christian König" <ckoenig.leichtzumerken@gmail.com>,
	tursulin@ursulin.net, matthew.brost@intel.com,
	sumit.semwal@linaro.org
Cc: dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org
Subject: Re: [PATCH 1/9] dma-buf: add dma_fence_was_initialized function v2
Date: Wed, 19 Aug 2026 14:51:47 +0200	[thread overview]
Message-ID: <5dd4248bccb446ef390e7149649632657db4aaae.camel@mailbox.org> (raw)
In-Reply-To: <0b84716fa6bec4e38d811dc76926dd81e31e0c81.camel@mailbox.org>

On Wed, 2026-08-19 at 14:33 +0200, Philipp Stanner wrote:


[…]

> 
> Regardless, looking at the code again, I would say that this might be a
> race, but I don't know enough about QXL to say for sure.
> 
> dma_fence_init() is (of course) not ordered:
> 
> 
> static void
> __dma_fence_init(struct dma_fence *fence, const struct dma_fence_ops *ops,
> 	         spinlock_t *lock, u64 context, u64 seqno, unsigned long flags)
> {
> 	BUG_ON(!ops || !ops->get_driver_name || !ops->get_timeline_name);
> 
> 	kref_init(&fence->refcount);
> 	/*
> 	 * While it is counter intuitive to protect a constant function pointer
> 	 * table by RCU it allows modules to wait for an RCU grace period
> 	 * before they unload, to make sure that nobody is executing their
> 	 * functions any more.
> 	 */
> 	RCU_INIT_POINTER(fence->ops, ops);
> 	INIT_LIST_HEAD(&fence->cb_list);
> 	fence->context = context;
> 	fence->seqno = seqno;
> 	fence->flags = flags | BIT(DMA_FENCE_FLAG_INITIALIZED_BIT);
> 
> (Should this maybe be set_bit() btw?)
> 
> 
> The fact that QXL could run into qxl_release_free() with an
> uninitialized fence hints at the fact that this might race, so
> DMA_FENCE_FLAG_INITIALIZED_BIT could be set / read before kref_init()
> ran.
> 
> 
> Maybe one way to verify / debug that would be to move
> spin_unlock(&qdev->release_idr_lock) downwards so it also guards
> dma_fence_was_initialized(), and also lock the initialization of the
> fence (in qxl_release_fence_buffer_objects() ?) with said lock.
> 
> If that's possible. Just brainstorming a bit for ways how to debug.
> 
> QXL does a few tricky things with the release->base.ops pointer.
> qxl_release_alloc() sets it to NULL, and only
> qxl_release_fence_buffer_objects() then actually sets it. So this could
> be the race? Setting of the ops pointer got replaced by setting of the
> fence-flag.
> 
> 
> P.

Could you test something like this? (not even compile-tested, just an idea)


diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 87797bea91cb..df1aa48b2809 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -1075,7 +1075,6 @@ __dma_fence_init(struct dma_fence *fence, const struct dma_fence_ops *ops,
        INIT_LIST_HEAD(&fence->cb_list);
        fence->context = context;
        fence->seqno = seqno;
-       fence->flags = flags | BIT(DMA_FENCE_FLAG_INITIALIZED_BIT);
        if (lock) {
                fence->extern_lock = lock;
        } else {
@@ -1084,6 +1083,8 @@ __dma_fence_init(struct dma_fence *fence, const struct dma_fence_ops *ops,
        }
        fence->error = 0;
 
+       smp_mb();
+       fence->flags = flags | BIT(DMA_FENCE_FLAG_INITIALIZED_BIT);
        trace_dma_fence_init(fence);
 }
 
diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
index b52ab692b22e..40ffdcafaac1 100644
--- a/include/linux/dma-fence.h
+++ b/include/linux/dma-fence.h
@@ -292,7 +292,12 @@ void dma_fence_describe(struct dma_fence *fence, struct seq_file *seq);
  */
 static inline bool dma_fence_was_initialized(struct dma_fence *fence)
 {
-       return fence && test_bit(DMA_FENCE_FLAG_INITIALIZED_BIT, &fence->flags);
+       bool init;
+
+       init = fence && test_bit(DMA_FENCE_FLAG_INITIALIZED_BIT, &fence->flags);
+       smp_mb();
+
+       return init;
 }
 
 /**

  reply	other threads:[~2026-08-19 12:51 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-20 10:54 Independence for dma_fences! v6 Christian König
2026-01-20 10:54 ` [PATCH 1/9] dma-buf: add dma_fence_was_initialized function v2 Christian König
2026-01-20 11:33   ` Tvrtko Ursulin
2026-07-13  8:58   ` Jiri Slaby
2026-07-14  7:53     ` Philipp Stanner
2026-07-14  8:43       ` Philipp Stanner
2026-08-19  8:59         ` Jiri Slaby
2026-08-19 12:33           ` Philipp Stanner
2026-08-19 12:51             ` Philipp Stanner [this message]
2026-08-28  7:29               ` Jiri Slaby
2026-08-28  7:46                 ` Jiri Slaby
2026-08-28  8:32                   ` Jiri Slaby
2026-01-20 10:54 ` [PATCH 2/9] dma-buf: protected fence ops by RCU v5 Christian König
2026-01-20 10:54 ` [PATCH 3/9] dma-buf: detach fence ops on signal v2 Christian König
2026-01-20 10:54 ` [PATCH 4/9] dma-buf: abstract fence locking Christian König
2026-01-20 10:54 ` [PATCH 5/9] dma-buf: inline spinlock for fence protection v4 Christian König
2026-01-20 11:41   ` Tvrtko Ursulin
2026-01-21  8:48     ` Christian König
2026-01-21  9:03       ` Tvrtko Ursulin
2026-01-27  4:56   ` kernel test robot
2026-01-20 10:54 ` [PATCH 6/9] dma-buf/selftests: test RCU ops and inline lock v2 Christian König
2026-01-20 10:54 ` [PATCH 7/9] dma-buf: use inline lock for the stub fence v2 Christian König
2026-01-21  9:29   ` Philipp Stanner
2026-01-20 10:54 ` [PATCH 8/9] dma-buf: use inline lock for the dma-fence-array Christian König
2026-01-20 10:54 ` [PATCH 9/9] dma-buf: use inline lock for the dma-fence-chain Christian König

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5dd4248bccb446ef390e7149649632657db4aaae.camel@mailbox.org \
    --to=phasta@mailbox.org \
    --cc=ckoenig.leichtzumerken@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jirislaby@kernel.org \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=matthew.brost@intel.com \
    --cc=phasta@kernel.org \
    --cc=sumit.semwal@linaro.org \
    --cc=tursulin@ursulin.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.