[RFC] drm: add unref_fb ioctl

[Rob Clark]

On Wed, May 10, 2017 at 11:11 AM, Daniel Vetter <daniel at ffwll.ch> 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 <seanpaul at chromium.org> 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 <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?
>>
>> In general, I'm ok w/ PUTFB as the name.. except GETFB is actually
>> more like GETFBINFO (ie. it doesn't take a ref).. so calling it PUTFB
>> implies it is the counterpart to GETFB when it really isn't.
>>
>> (I suppose technically we could rename GETFB to something else without
>> breaking ABI, and since we copy the headers into libdrm it might not
>> be *that* big a pita..)
>
> If we bikeshed the name, CLOSEFB? It is not an unreference operation,
> since the drm_file fb reference is not refcounted. The underlying fb is,
> but not the per-file reference (which is the thing we nuke here).
>
> This is similar to closing files, which will close it even if you have
> piles of other references to the same fd in userspace (but the underlying
> struct file in the kernel might or might not disappear). Seems more
> fitting to me than either UNREF or PUT. Also fits with GEM_CLOSE on the
> gem side, which works the same way (it just drops the drm_file reference,
> nothing else).

yeah, I like CLOSEFB

BR,
-R

> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch