From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
To: Ville Syrjala <ville.syrjala@linux.intel.com>,
dri-devel@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org, stable@vger.kernel.org,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Abhay Kumar <abhay.kumar@intel.com>
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 [thread overview]
Message-ID: <a9ae1a15-6ff8-c940-ff10-ec8dfbb46c4b@linux.intel.com> (raw)
In-Reply-To: <20180502183247.5746-1-ville.syrjala@linux.intel.com>
Op 02-05-18 om 20:32 schreef Ville Syrjala:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> 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 <maarten.lankhorst@linux.intel.com>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: Abhay Kumar <abhay.kumar@intel.com>
> Fixes: 581e49fe6b41 ("drm/atomic: Add new iterators over all state, v3.")
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
OUCH! Good catch..
~Maarten
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
How come KASAN didn't complain?
prev parent reply other threads:[~2018-05-03 7:46 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-02 18:32 [PATCH] drm/atomic: Clean old_state/new_state in drm_atomic_state_default_clear() Ville Syrjala
2018-05-02 19:12 ` ✓ Fi.CI.BAT: success for " Patchwork
2018-05-03 1:35 ` ✓ Fi.CI.IGT: " Patchwork
2018-05-03 6:35 ` [PATCH] " Daniel Vetter
2018-05-03 10:41 ` Ville Syrjälä
2018-05-03 14:48 ` [Intel-gfx] " Ville Syrjälä
2018-05-03 7:46 ` Maarten Lankhorst [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a9ae1a15-6ff8-c940-ff10-ec8dfbb46c4b@linux.intel.com \
--to=maarten.lankhorst@linux.intel.com \
--cc=abhay.kumar@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=stable@vger.kernel.org \
--cc=ville.syrjala@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.