[PATCH xf86-video-ati 5/6] Make all active CRTCs scan out an all-black framebuffer in LeaveVT

[Emil Velikov]

On 30 August 2017 at 09:04, Michel Dänzer <michel at daenzer.net> wrote:
> On 29/08/17 07:56 PM, Emil Velikov wrote:
>> On 28 August 2017 at 10:23, Michel Dänzer <michel at daenzer.net> wrote:
>>> From: Michel Dänzer <michel.daenzer at amd.com>
>>>
>>> And destroy all other FBs. This is so that other DRM masters can only
>>> get access to this all-black FB, not to any other FB we created, while
>>> we're switched away and not DRM master.
>>>
>> Isn't the issue applicable overall - be that in X, wayland compositors, other?
>
> Potentially.
>
Ack, ty.

>
>> IIRC the vmwgfx's kernel driver, which has extra locking [1] in order
>> to address that.
>> Would a similar approach like that be applicable for radeon/amdgpu?
>
> I don't see how that's related.
>
> The issue is that if the caller of DRM_IOCTL_MODE_GETFB is DRM master
> (or root, or using a DRM control device node), the ioctl returns a valid
> GEM handle for the framebuffer, so the caller can use the underlying
> buffer arbitrarily. This is handled by core DRM code, there's nothing
> kernel drivers can do about it.
>
Disclaimer: I'm might be a mile off.

vmgfx's vmw_master_check() which does the usual DRM master/control or
root checking.
There is a "Check if we were previously master, but now dropped" which
seems, perhaps too vaguely, related to what's happening here.

Admittedly I've not looked too closely at the locked_master and
associated ttm code (ttm_read_lock, etc).
But was under the impression that it is used to restrict access to the
[contents behind the] GEM handle, when DRM master is dropped.

That said, I'm silly - vmwgfx specifics in a radeon/ati thread is not
the right thing.

Thanks
Emil