lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 21 Feb 2017 11:52:28 +0100 From: Thomas Hellstrom <thomas@...pmail.org> To: David Airlie <airlied@...hat.com> Cc: Daniel Vetter <daniel.vetter@...ll.ch>, Intel Graphics Development <intel-gfx@...ts.freedesktop.org>, DRI Development <dri-devel@...ts.freedesktop.org>, Daniel Vetter <daniel.vetter@...el.com>, linux-kernel@...r.kernel.org Subject: Re: DRM_CONTROL node breakage (Re: [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes) On 02/21/2017 06:34 AM, David Airlie wrote: >> No. >> >> IMO Not fixing this immediately through stable is out of the question. >> The deal is that we don't break userspace. >> Having said that, I'm not against a long term vmwgfx-only solution. But >> let's fix this now. >> >> Admittedly we missed testing this but you got to understand that not all >> developer teams have a multitude of >> developers (we have on average one for the whole linux graphics driver >> stack except GL), and the bug >> doesn't show up for QE on regression testing unless they run >> gnome-sheel/Wayland which they currently don't, and I guess they've been >> focused on the fb2 regression. >> >> It's no secret that we've been using the control nodes for some time. >> The CONTROL_ALLOW is present in the >> driver private ioctls and the commit has been there since 2016. >> >> The user-space code has been present in vmware-tools also since that >> commit and due to the long release cycles of >> open-vm-tools the open-vm-tools version was just about to be released. >> It's necessary for non-xorg > can you send a revert against drm-next? I'm not sure how clean it will be. > > there might be an intermediate step. > > Then can we port vmtools of this behaviour, not even sure what it is doing. > > Dave. So after a quick investigation of the impact it looks like the daemon patch was pulled out of the Fedora open-vm-tools update in time. This limits the impact to within VMware where we can update the daemon code and rerun the test cycle. I've posted a patch that makes it possible for us to use render-nodes instead of control nodes. /Thomas
Powered by blists - more mailing lists