On Thu, 05 Nov 2026 08:49:49 +0100, Philipp Stanner wrote:
> >
> > drivers/dma-buf/sw_sync.c | 6 +++++-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/dma-buf/sw_sync.c b/drivers/dma-buf/sw_sync.c
> > index 8df20b0218a9..261bc98b1ed6 100644
> > --- a/drivers/dma-buf/sw_sync.c
> > +++ b/drivers/dma-buf/sw_sync.c
> > @@ -221,7 +221,11 @@ static void sync_timeline_signal(struct sync_timeline
> > *obj, unsigned int inc)
> > if (!timeline_fence_signaled(&pt->base))
> > break;
> >
> > - dma_fence_get(&pt->base);
> > + if (!dma_fence_get_rcu(&pt->base)) {
>
> You must hold the rcu_read_lock() while doing that, don't you?
dma_fence_get_rcu() is simply a wrapper around kref_get_unless_zero(),
it has nothing to do with RCU. For instance, the use of dma_fence_get_rcu()
within sync_pt_create(), as seen in the SW_SYNC_IOC_CREATE_FENCE code path
does not require an RCU lock.
>
> This probably works "by coincidence" since the surrounding spinlock
> also disables preemption, like the rcu lock does.
>
> That spinlock, why can't it guard the dma_fence reference? Doesn't obj-
> >pt_list hold its own reference?
This is neither a coincidence nor related to any outer spinlock.
The comments I included in my patch provide a complete explanation of
the fence's reference counting, from the moment of its creation to its
final destruction.
BR,
Edward
