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
