On 30/08/17 07:27 PM, Emil Velikov wrote: > 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: >> >>> 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. I'm not familiar with that code either, so I may be wrong, but AFAICT it's kind of the opposite, allowing userspace which was previously DRM master to do some things it otherwise wouldn't be allowed to do. Whereas this change is about something userspace can do while it's DRM master, and which cannot be disallowed per se without breaking userspace (e.g. smooth bootsplash -> login screen -> user session transitions). -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
