On Wed, May 10, 2017 at 2:27 AM, Daniel Vetter <daniel@xxxxxxxx> wrote: > On Wed, May 10, 2017 at 8:26 AM, Daniel Vetter <daniel@xxxxxxxx> 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, 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. hmm, it would seem unusual for incoming process to inherit any fb's *other* than what is on screen (what else would be holding a ref to keep them live?) It did occur to me that we could keep a list of "weakly ref'd" fb's in drm_file to kill at lastclose. Not entirely sure if that is useful or not.. would need feedback from various userspaces. (I did leave room for a flags field, so we could add kill-on-close flag later.) BR, -R >> Other > > Oops, hit send too early: Otherwise looks good. Well, you can forgo > the kernel-doc (just leave a comment if you want to explain the > difference), since in drm core only the driver interface stuff is > documented with kernel-doc. At least that's what I've been doing. > > -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
