On Wed, May 10, 2017 at 08:26:42AM +0200, Daniel Vetter wrote: > On Tue, May 9, 2017 at 5:36 PM, Rob Clark <robdclark@xxxxxxxxx> 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 of a problem really, Agreed. I've been under the impression that relying on pipe cleanup in rmfb is a somewhat inelegant thing to do anyways. One bikeshed comment I have is with the name. We've moved everything from *_unreference to *_put. To stay consistent with that, as well as balance out GETFB, could we rename to PUTFB? Sean > or at least I suspect > we have bigger issues: the GETFB ioctl allows you to get at the gem bo > behind any framebuffer, as long as you're the current master. There's > no need for that framebuffer to be active on the screen. Not sure > that's a good idea really, we might want to fix up that ioctl to only > hand out the backing storage objects for currently active objects. But > kinda separate issue. > > Other > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > _______________________________________________ > dri-devel mailing list > dri-devel@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Sean Paul, Software Engineer, Google / Chromium OS _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
