[RFC] drm: add unref_fb ioctl

[Rob Clark]

On Wed, May 10, 2017 at 2:27 AM, Daniel Vetter <daniel at ffwll.ch> wrote:
> On Wed, May 10, 2017 at 8:26 AM, Daniel Vetter <daniel at ffwll.ch> 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, 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