diff options
author | David Herrmann <dh.herrmann@gmail.com> | 2014-07-22 15:12:26 (GMT) |
---|---|---|
committer | David Herrmann <dh.herrmann@gmail.com> | 2014-08-05 14:07:55 (GMT) |
commit | 3cb01a980461506f9ec4e4e1dc2dab6314236fb7 (patch) | |
tree | e35eb24679bda6f69a1f216ba33522b603262dc7 /arch/m68k | |
parent | 48ba813701eb14b3008edefef4a0789b328e278c (diff) | |
download | linux-3cb01a980461506f9ec4e4e1dc2dab6314236fb7.tar.xz |
drm: don't de-authenticate clients on master-close
If an active DRM-Master closes its device, we deauthenticate all clients
on that master. However, if an inactive DRM-Master closes its device, we
do nothing. This is quite inconsistent and breaks several scenarios:
1) If this was used as security mechanism, it fails horribly if a master
closes a device while VT switched away. Furthermore, none of the few
drivers using ->master_*() callbacks seems to require it, anyway.
2) If you spawn weston (or any other non-UMS compositor) in background
while another compositor is active, both will get assigned to the
same "drm_master" object. If the foreground compositor now exits, all
clients of both the foreground AND background compositor will be
de-authenticated leading to unexpected behavior.
Stop this non-sense and keep clients authenticated. We don't do this when
dropping DRM-Master (i.e., switching VTs) so don't do it on active-close
either!
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Diffstat (limited to 'arch/m68k')
0 files changed, 0 insertions, 0 deletions