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

From: Daniel Vetter <daniel@ffwll.ch>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	Daniel Vetter <daniel@ffwll.ch>,
	dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
	Sean Paul <seanpaul@chromium.org>,
	Zach Reizner <zachr@google.com>,
	Gustavo Padovan <gustavo.padovan@collabora.co.uk>,
	Daniel Vetter <daniel.vetter@ffwll.ch>
Subject: Re: [Intel-gfx] [PATCH v3] drm/vgem: Attach sw fences to exported vGEM dma-buf (ioctl)
Date: Fri, 15 Jul 2016 09:08:40 +0200	[thread overview]
Message-ID: <20160715070840.GK17101@phenom.ffwll.local> (raw)
In-Reply-To: <20160714152441.GB22927@nuc-i3427.alporthouse.com>

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. Ḯ'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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel