From patchwork Fri Mar 11 09:34:04 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: 12777708 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 348A9C4332F 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: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:In-Reply-To:References: List-Owner; bh=ZVwmzGv00Ql2i4NTx24BPFA9xGgXxE4L/ifqDol9k3Y=; b=EthJUCPnHhJ3fI EgSar8Njz/xZNMc93OARLjn5ACDFAKW4D05Y6m17HjFs0kwYLSs8Q9ZpGD5A+GMkRsFHYGJifP6Uw 9k51Fy2kHmcFLyTfRouMtoHS7tFKxOvuViREqhGQNSSzedmwFUiFiJh1JxwLwTs73ULczWrBq5bEd Av3eKbuS3l1zW5m56EABdBDV8T/p1aXaPs82ByVs66+Eh68aqco3kH7hzpNkXyFKEzCBwAApRiFb+ ssGICWb+suDOnOotI9PEkXO5kFOzKJl4j6SOq2XJHgooa+M7gPi1mywinApcR/ziKtglF/AdjjUGF pgVx2TX2LHVVhnGEBoMA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nSbfT-00Fp4J-Vx; Fri, 11 Mar 2022 09:34:39 +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-00Fp2q-SO 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 2CCEC1F46496 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1646991274; bh=Jse5jslyQwK8jYrGmsf8TVyXCyfWaI4dN1Xg9g/UKcA=; h=From:To:Cc:Subject:Date:From; b=IpFgOc0TudE0KJyzh7uv590XVGZF6klHXcFh6GrFFLQyRGb/YAofcmFwQ+BjhVEbw TbmFtww7jSInDHtYABfZbAIXJLwkAwwf2fc3I+jAAnV23uItwiZMmAqtoQr1JZzTFr oqaGb/Uch5ozrOKkk4nfOT8lvzrsJCisO4KM5bh8XJMB3HVVkYuIrHD9kFMMdT28mX MR6UWePzBT8als4P/ngrk66/on8Q1Kak/rTTMMd7nbUDHz0UCS3qhPs9CkH0kmEH5G ImflviUi5gPK+n31hBNaCBNIRnjrv1PCLbMHWE8IDk/RitGJperU5lHrWHTJgeLbvr ya8JKpVqTlGRQ== 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 0/2 RESEND] Mitigate race condition problems when unbinding DRM driver Date: Fri, 11 Mar 2022 10:34:04 +0100 Message-Id: <20220311093406.4068019-1-ricardo.canuelo@collabora.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220311_013438_101940_E90B0BBB X-CRM114-Status: GOOD ( 13.95 ) 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 Hi all, I'm sending these patches to try to improve the current situation for a particular corner case (DRM driver unbinding). I could reproduce a specific race condition during the unbinding of the mediatek-drm driver that caused an invalid memory address. The race condition is triggered by a userspace event (gnome-shell requesting a DRM GET_CONNECTOR ioctl) while the encoders and drivers are in the process of being disabled. While I tried to mitigate this by making a small change in the parade-ps8640 driver (for the bridge I'm testing on) and by making a couple of functions in drm_bridge.c more robust, this is only a symptom of a larger problem that might not be getting enough attention, understandably, because this is an unusual corner case. The scenario looks like this: : unbind mediatek-drm --------------------+ | | | | | ... | | ... mtk_dsi_unbind | | | `- drm_encoder_cleanup v | | gnome-shell ... `- drm_bridge_detach *<------ ioctl (GET_CONNECTOR) | | ... | | ps8640_bridge_get_edid | `drm_bridge_chain_post_disable which causes drm_bridge_chain_post_disable() to walk the bridge chain after the bridge has already been detached and removed from the list. I guess a more radical and subsystem-wide solution would be to not allow or to block certain ioctl calls once the driver has started to unbind, but I'd like to hear your opinion on this. This was tested on an Acer Chromebook R13 (Elm, MT8173) running Debian Sid, the command that triggers the race condition is echo mediatek-drm.12.auto > /sys/bus/platform/drivers/mediatek-drm/unbind Cheers, Ricardo Ricardo Cañuelo (2): drm/bridge: parade-ps8640: avoid race condition on driver unbinding drm/bridge: Add extra checks in pre_enable and post_enable drivers/gpu/drm/bridge/parade-ps8640.c | 6 +++--- drivers/gpu/drm/drm_bridge.c | 4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-) --- 2.25.1