[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <bb78f340-4a37-33ad-55d6-805f64e1389c@collabora.com>
Date: Fri, 18 Mar 2022 11:21:59 +0100
From: AngeloGioacchino Del Regno
<angelogioacchino.delregno@...labora.com>
To: Ricardo Cañuelo <ricardo.canuelo@...labora.com>,
dri-devel@...ts.freedesktop.org
Cc: linux-kernel@...r.kernel.org, linux-mediatek@...ts.infradead.org,
kernel@...labora.com, andrzej.hajda@...el.com,
narmstrong@...libre.com, maarten.lankhorst@...ux.intel.com,
mripard@...nel.org
Subject: Re: [PATCH 1/2 RESEND] drm/bridge: parade-ps8640: avoid race
condition on driver unbinding
Il 11/03/22 10:34, Ricardo Cañuelo ha scritto:
> When unbinding a DRM master driver there's a race condition that
> sometimes results in an invalid vm access when userspace (gnome-shell)
> issues a DRM_IOCTL_MODE_GETCONNECTOR ioctl right after a bridge has been
> removed from an encoder's bridge chain.
>
> This means that once a bridge has been disabled and gone through
> ps8640_post_disable(), if ps8640_bridge_get_edid() runs afterwards as a
> result of that ioctl call it will call drm_bridge_chain_pre_enable()
> and drm_bridge_chain_post_disable() again in a bridge that has been
> already detached.
>
> Setting `ps_bridge->pre_enabled = false` at a later stage of the
> bringdown path and calling drm_bridge_chain_pre_enable() inside
> ps8640_bridge_get_edid() only if needed avoid this, although a proper
> subsystem-wide fix would be the proper solution, since the same type of
> race conditions might happen somewhere else.
>
> Tested on an Acer Chromebook R13 (Elm, MT8173) with Debian Sid.
>
> Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@...labora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
> ---
> drivers/gpu/drm/bridge/parade-ps8640.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
Powered by blists - more mailing lists