[Intel-gfx] [PATCH 01/40] drm: Use default dma_fence hooks where possible for null syncobj

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-09-20 14:34:29)
> 
> On 19/09/2018 20:55, Chris Wilson wrote:
> > Both the .enable_signaling and .release of the null syncobj fence
> > can be replaced by the default callbacks for a small reduction in code
> > size.
> > 
> > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > ---
> >   drivers/gpu/drm/drm_syncobj.c | 11 -----------
> >   1 file changed, 11 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
> > index 497729202bfe..e254f97fed7d 100644
> > --- a/drivers/gpu/drm/drm_syncobj.c
> > +++ b/drivers/gpu/drm/drm_syncobj.c
> > @@ -66,20 +66,9 @@ static const char *drm_syncobj_stub_fence_get_name(struct dma_fence *fence)
> >           return "syncobjstub";
> >   }
> >   
> > -static bool drm_syncobj_stub_fence_enable_signaling(struct dma_fence *fence)
> > -{
> > -    return !dma_fence_is_signaled(fence);
> > -}
> > -
> > -static void drm_syncobj_stub_fence_release(struct dma_fence *f)
> > -{
> > -     kfree(f);
> > -}
> 
> With the default implementation this becomes kfree_rcu - so 
> theoretically a change in behaviour after all.

A correction, since dma_fence are required to be RCU safe.
 
> Since there are RCU usages in syncobj and the magical null/stub handle 
> is not explained (or I did not find it), was the code fine with a plain 
> kfree?

No :) It's the third parties who may be doing RCU lookups, the only
argument would be that it would never be exposed... Except it was.
-Chris