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