From patchwork Fri Mar 11 09:34:05 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Ricardo_Ca=C3=B1uelo?= X-Patchwork-Id: 12777709 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id EFE35C433FE for ; Fri, 11 Mar 2022 09:34:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-Id:Date:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=V2kx2/G84xlpcWK+TahXIXZ93px5tEJRcGb5NCfcFVE=; b=FTsUgZv8VbIZcR UN5waKFmKYmI9q9vMUV6OyhbKyZCY2lv8f3+afHz7bsegMgzRbqWsa/sNlUpHu1dzqTEYl9u8YjTy F0pTGChJYl+9oQOpw9MBftBLECusFw0/l2SVU6O2Ydn+6sNHktoicFpt5Peb3SIyaJZdEnNV62E+O AShQYBU8Q3MetK1i07zOKY9KAra3COjqsuY5HaHmBYoCesOP/0ga5Dpe5xfS6tE5R/yUQZFx5BVDf YmsLbOFKELC1erOLTDfgV7vJVSszMulz+5Rrzy2wonv/fcdaFShc4ZBwsN54fl2rIXKKfN8XnRVEd xN0v4UjSZjXKuaJQEZ4g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nSbfV-00Fp4z-24; Fri, 11 Mar 2022 09:34:41 +0000 Received: from bhuna.collabora.co.uk ([2a00:1098:0:82:1000:25:2eeb:e3e3]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nSbfR-00Fp35-Ti for linux-mediatek@lists.infradead.org; Fri, 11 Mar 2022 09:34:39 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: rcn) with ESMTPSA id 43B4C1F4649B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1646991276; bh=PEG3axVN//YyYVluyyyZUdTkTfte6RZExlKRrKGNNGg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=IOIevA2nantASE3yYn/YUjQS5gP8DD6vEldy8ZnQb7KvSWDexaKr23Q1H3WWldHVX ilMRsF/w8dhmsry9dwQLfOy74iekWPbrKv7KmwjLbbymuI2OupBFSkb0a0Yz6wcVYt eJttIa1fKq1b9rKZnUfRuveC31R3UQ4sqv5aNCGlEiO3fcFGAtfhrZJKiLoQ41KAzc BuGtK0m5eqWa4/7L+i4DCr+9g3CzUy7kEfBv/ebnRbUDdEXply9m6eEh/Yo3PKNic4 9wSSwSlwtBBz6x0ComHm5IrbBXghXwrwqHzMnOBxMa+Ep6dqpMnr7Ey5Lh+ediB8wS fxrSGXNY4OdkQ== From: =?utf-8?q?Ricardo_Ca=C3=B1uelo?= To: dri-devel@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org, kernel@collabora.com, andrzej.hajda@intel.com, narmstrong@baylibre.com, maarten.lankhorst@linux.intel.com, mripard@kernel.org Subject: [PATCH 1/2 RESEND] drm/bridge: parade-ps8640: avoid race condition on driver unbinding Date: Fri, 11 Mar 2022 10:34:05 +0100 Message-Id: <20220311093406.4068019-2-ricardo.canuelo@collabora.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220311093406.4068019-1-ricardo.canuelo@collabora.com> References: <20220311093406.4068019-1-ricardo.canuelo@collabora.com> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220311_013438_120438_F9E5EFBE X-CRM114-Status: GOOD ( 12.88 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org 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 Reviewed-by: AngeloGioacchino Del Regno --- drivers/gpu/drm/bridge/parade-ps8640.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c b/drivers/gpu/drm/bridge/parade-ps8640.c index 3f17337ee389..a927787a89bf 100644 --- a/drivers/gpu/drm/bridge/parade-ps8640.c +++ b/drivers/gpu/drm/bridge/parade-ps8640.c @@ -434,8 +434,6 @@ static void ps8640_post_disable(struct drm_bridge *bridge) { struct ps8640 *ps_bridge = bridge_to_ps8640(bridge); - ps_bridge->pre_enabled = false; - ps8640_bridge_vdo_control(ps_bridge, DISABLE); pm_runtime_put_sync_suspend(&ps_bridge->page[PAGE0_DP_CNTL]->dev); } @@ -487,6 +485,7 @@ static void ps8640_bridge_detach(struct drm_bridge *bridge) drm_dp_aux_unregister(&ps_bridge->aux); if (ps_bridge->link) device_link_del(ps_bridge->link); + ps_bridge->pre_enabled = false; } static struct edid *ps8640_bridge_get_edid(struct drm_bridge *bridge, @@ -508,7 +507,8 @@ static struct edid *ps8640_bridge_get_edid(struct drm_bridge *bridge, * EDID, for this chip, we need to do a full poweron, otherwise it will * fail. */ - drm_bridge_chain_pre_enable(bridge); + if (poweroff) + drm_bridge_chain_pre_enable(bridge); edid = drm_get_edid(connector, ps_bridge->page[PAGE0_DP_CNTL]->adapter);