[Intel-gfx] [PATCH v3] drm/vgem: Attach sw fences to exported vGEM dma-buf (ioctl)

[Daniel Vetter]

On Thu, Jul 14, 2016 at 04:24:41PM +0100, Chris Wilson wrote:
> On Thu, Jul 14, 2016 at 04:36:37PM +0200, Daniel Vetter wrote:
> > On Thu, Jul 14, 2016 at 02:39:54PM +0100, Chris Wilson wrote:
> > > On Thu, Jul 14, 2016 at 02:23:04PM +0100, Chris Wilson wrote:
> > > > The biggest reason I had against going the sw_sync only route was that
> > > > vgem should provide unprivileged fences and that through the bookkeeping
> > > > in vgem we can keep them safe, ensure that we don't leak random buffers
> > > > or fences. (And I need a source of foriegn dma-buf with implicit fence
> > > > tracking with which I can try and break the driver.)
> > > 
> > > And for testing passing around content + fences is more useful than
> > > passing fences alone.
> > 
> > Yup, agreed. But having fences free-standing isn't a real issue since
> > their refcounted and the userspace parts (sync_file) will get cleaned up
> > on process exit latest. Ḯ'm not advocating for any behaviour change at
> > all, just for hiding these things in debugfs.
> 
> It's just a choice of api. We could equally hide it behind a separate
> config flag.
> 
> First question, are we happy that there is a legitimate usecase for fences
> on vgem?
> 
> If so, what enforced timeout on the fence should we use?
> 
> (I think that this ioctl api is correct, I don't forsee sw_sync being
> viable for unprivileged use.)
> 
> Then we can restrict this patch to add the safe interface, enable a bunch
> more tests and get on with discussing how to break the kernel "safely"!

I think the interface is sound. We could probably bikeshed the timeout
forever, but 10s is still reasonable imo.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch