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@xxxxxxxxxxxxxxxxxx>
> > ---
> > 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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
