[Intel-gfx] [PATCH 1/2] drm/dp: Read the tx msg state once after checking for an event
Daniel Vetter
daniel at ffwll.ch
Mon May 15 12:02:49 UTC 2017
On Sat, May 13, 2017 at 11:52:00AM +0100, Chris Wilson wrote:
> Both as an exercise to document that we are reading the state outside of
> the appropriate mutex and to ensure that we only read the value once
> before the multiple comparisons, use READ_ONCE.
I think gcc could also opt to re-evalute and re-load it, resulting to
diverging control flow and hilarity. At least I don't spot any protection
against that in the wait_for macros.
Applied to drm-misc, thanks.
-Daniel
>
> Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c
> index d1cbb9c8f806..3bdd314f02b1 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -737,16 +737,16 @@ static void drm_dp_mst_put_payload_id(struct drm_dp_mst_topology_mgr *mgr,
> static bool check_txmsg_state(struct drm_dp_mst_topology_mgr *mgr,
> struct drm_dp_sideband_msg_tx *txmsg)
> {
> - bool ret;
> + unsigned int state;
>
> /*
> * All updates to txmsg->state are protected by mgr->qlock, and the two
> * cases we check here are terminal states. For those the barriers
> * provided by the wake_up/wait_event pair are enough.
> */
> - ret = (txmsg->state == DRM_DP_SIDEBAND_TX_RX ||
> - txmsg->state == DRM_DP_SIDEBAND_TX_TIMEOUT);
> - return ret;
> + state = READ_ONCE(txmsg->state);
> + return (state == DRM_DP_SIDEBAND_TX_RX ||
> + state == DRM_DP_SIDEBAND_TX_TIMEOUT);
> }
>
> static int drm_dp_mst_wait_tx_reply(struct drm_dp_mst_branch *mstb,
> --
> 2.11.0
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
More information about the dri-devel
mailing list