Re: [RFC] drm: add unref_fb ioctl

2017-05-11 Thread Daniel Vetter
On Thu, May 11, 2017 at 04:45:09PM +0900, Michel Dänzer wrote: > On 10/05/17 10:16 PM, Daniel Vetter wrote: > > On Wed, May 10, 2017 at 1:24 PM, Rob Clark wrote: > >> On Wed, May 10, 2017 at 2:27 AM, Daniel Vetter wrote: > >>> On Wed, May 10, 2017 at 8:26 AM, Daniel Vetter wrote: > On Tue,

Re: [RFC] drm: add unref_fb ioctl

2017-05-11 Thread Michel Dänzer
On 10/05/17 10:16 PM, Daniel Vetter wrote: > On Wed, May 10, 2017 at 1:24 PM, Rob Clark wrote: >> On Wed, May 10, 2017 at 2:27 AM, Daniel Vetter wrote: >>> On Wed, May 10, 2017 at 8:26 AM, Daniel Vetter wrote: On Tue, May 9, 2017 at 5:36 PM, Rob Clark wrote: > Disadvantages: > *

Re: [RFC] drm: add unref_fb ioctl

2017-05-10 Thread Rob Clark
On Wed, May 10, 2017 at 11:11 AM, Daniel Vetter wrote: > On Wed, May 10, 2017 at 10:20:09AM -0400, Rob Clark wrote: >> On Wed, May 10, 2017 at 9:48 AM, Sean Paul wrote: >> > On Wed, May 10, 2017 at 08:26:42AM +0200, Daniel Vetter wrote: >> >> On Tue, May 9, 2017 at 5:36 PM, Rob Clark wrote: >> >

Re: [RFC] drm: add unref_fb ioctl

2017-05-10 Thread Daniel Vetter
On Wed, May 10, 2017 at 10:20:09AM -0400, Rob Clark wrote: > On Wed, May 10, 2017 at 9:48 AM, Sean Paul wrote: > > On Wed, May 10, 2017 at 08:26:42AM +0200, Daniel Vetter wrote: > >> On Tue, May 9, 2017 at 5:36 PM, Rob Clark wrote: > >> > Disadvantages: > >> > * depending on userspace architect

Re: [RFC] drm: add unref_fb ioctl

2017-05-10 Thread Rob Clark
On Wed, May 10, 2017 at 9:48 AM, Sean Paul wrote: > On Wed, May 10, 2017 at 08:26:42AM +0200, Daniel Vetter wrote: >> On Tue, May 9, 2017 at 5:36 PM, Rob Clark wrote: >> > Disadvantages: >> > * depending on userspace architecture, layers left on screen could >> > be considered an informatio

Re: [RFC] drm: add unref_fb ioctl

2017-05-10 Thread Sean Paul
On Wed, May 10, 2017 at 08:26:42AM +0200, Daniel Vetter wrote: > On Tue, May 9, 2017 at 5:36 PM, Rob Clark wrote: > > Disadvantages: > > * depending on userspace architecture, layers left on screen could > > be considered an information leak, ie. new incoming master process > > has acces

Re: [RFC] drm: add unref_fb ioctl

2017-05-10 Thread Daniel Vetter
On Wed, May 10, 2017 at 1:24 PM, Rob Clark wrote: > On Wed, May 10, 2017 at 2:27 AM, Daniel Vetter wrote: >> On Wed, May 10, 2017 at 8:26 AM, Daniel Vetter wrote: >>> On Tue, May 9, 2017 at 5:36 PM, Rob Clark wrote: Disadvantages: * depending on userspace architecture, layers left o

Re: [RFC] drm: add unref_fb ioctl

2017-05-10 Thread Rob Clark
On Wed, May 10, 2017 at 2:27 AM, Daniel Vetter wrote: > On Wed, May 10, 2017 at 8:26 AM, Daniel Vetter wrote: >> On Tue, May 9, 2017 at 5:36 PM, Rob Clark wrote: >>> Disadvantages: >>> * depending on userspace architecture, layers left on screen could >>> be considered an information leak,

Re: [RFC] drm: add unref_fb ioctl

2017-05-09 Thread Daniel Vetter
On Wed, May 10, 2017 at 8:26 AM, Daniel Vetter wrote: > On Tue, May 9, 2017 at 5:36 PM, Rob Clark wrote: >> Disadvantages: >> * depending on userspace architecture, layers left on screen could >> be considered an information leak, ie. new incoming master process >> has access to buffers

Re: [RFC] drm: add unref_fb ioctl

2017-05-09 Thread Daniel Vetter
On Tue, May 9, 2017 at 5:36 PM, Rob Clark wrote: > Disadvantages: > * depending on userspace architecture, layers left on screen could > be considered an information leak, ie. new incoming master process > has access to buffers that are still being scanned out. I'm not sure this is much