[RFC] drm: add unref_fb ioctl

Sean Paul seanpaul at chromium.org
Wed May 10 13:48:49 UTC 2017


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 at gmail.com> 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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Sean Paul, Software Engineer, Google / Chromium OS


More information about the dri-devel mailing list