From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jani Nikula Subject: Re: [PATCH] drm: Fix an unwanted master inheritance v2 Date: Fri, 04 Dec 2015 10:25:20 +0200 Message-ID: <87bna61uz3.fsf@intel.com> References: <1449077086-3125-1-git-send-email-thellstrom@vmware.com> <87wpsv23bh.fsf@intel.com> <5660A5CB.1000702@vmware.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: In-Reply-To: <5660A5CB.1000702@vmware.com> Sender: stable-owner@vger.kernel.org To: Thomas Hellstrom , dri-devel@lists.freedesktop.org, linux-graphics-maintainer@vmware.com Cc: pv-drivers@vmware.com, stable@vger.kernel.org List-Id: dri-devel@lists.freedesktop.org On Thu, 03 Dec 2015, Thomas Hellstrom wrote: > Hi, > > On 12/03/2015 12:12 PM, Jani Nikula wrote: >> On Wed, 02 Dec 2015, Thomas Hellstrom wrote: >>> A client calling drmSetMaster() using a file descriptor that was opened >>> when another client was master would inherit the latter client's master >>> object and all its authenticated clients. >>> >>> This is unwanted behaviour, and when this happens, instead allocate a >>> brand new master object for the client calling drmSetMaster(). >>> >>> Fixes a BUG() throw in vmw_master_set(). >>> >>> Cc: >>> Signed-off-by: Thomas Hellstrom >> Drive-by bikeshedding, the actual change might look neater (and easier >> to revert if something falls apart) if you extracted the >> drm_new_set_master() abstraction as a separate non-functional prep >> patch. Not insisting, just a thought. >> >> BR, >> Jani. > While you're probably right, I prefer to have this as a single patch to > avoid ending up in a backporting nightmare for stable. That's reasonable. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center