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"! -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
