From mboxrd@z Thu Jan 1 00:00:00 1970 From: Maarten Lankhorst Subject: Re: [PATCH] drm/atomic: Clean old_state/new_state in drm_atomic_state_default_clear() Date: Thu, 3 May 2018 09:46:25 +0200 Message-ID: References: <20180502183247.5746-1-ville.syrjala@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: In-Reply-To: <20180502183247.5746-1-ville.syrjala@linux.intel.com> Content-Language: en-US Sender: stable-owner@vger.kernel.org To: Ville Syrjala , dri-devel@lists.freedesktop.org Cc: intel-gfx@lists.freedesktop.org, stable@vger.kernel.org, Laurent Pinchart , Abhay Kumar List-Id: dri-devel@lists.freedesktop.org Op 02-05-18 om 20:32 schreef Ville Syrjala: > From: Ville Syrjälä > > Clear the old_state and new_state pointers for every object in > drm_atomic_state_default_clear(). Otherwise > drm_atomic_get_{new,old}_*_state() will hand out stale pointers to > anyone who hasn't first confirmed that the object is in fact part of > the current atomic transcation, if they are called after we've done > the ww backoff dance while hanging on to the same drm_atomic_state. > > For example, handle_conflicting_encoders() looks like it could hit > this since it iterates the full connector list and just calls > drm_atomic_get_new_connector_state() for each. > > And I believe we have now witnessed this happening at least once in > i915 check_digital_port_conflicts(). Commit 8b69449d2663 ("drm/i915: > Remove last references to drm_atomic_get_existing* macros") changed > the safe drm_atomic_get_existing_connector_state() to the unsafe > drm_atomic_get_new_connector_state(), which opened the doors for > this particular bug there as well. > > Cc: stable@vger.kernel.org > Cc: Maarten Lankhorst > Cc: Laurent Pinchart > Cc: Abhay Kumar > Fixes: 581e49fe6b41 ("drm/atomic: Add new iterators over all state, v3.") > Signed-off-by: Ville Syrjälä > --- OUCH! Good catch.. ~Maarten Reviewed-by: Maarten Lankhorst How come KASAN didn't complain?