[RFC] drm: add unref_fb ioctl

[Daniel Vetter]

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).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch