Re: [RFC] drm: add unref_fb ioctl

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, May 10, 2017 at 9:48 AM, Sean Paul <seanpaul@xxxxxxxxxxxx> 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@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,
>
> 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..)

BR,
-R


> 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@xxxxxxxxxxxxxxxxxxxxx
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Sean Paul, Software Engineer, Google / Chromium OS
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux