From patchwork Fri Feb 25 13:45:02 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: 12760362 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 99C3CC433EF for ; Fri, 25 Feb 2022 13:55:05 +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=SuY5jQR5d17tPV bkQ8iAzeF4keoyvwDmSno1d/pDZhZ+XMXcq++nPFcHYfTgaQpWtvl1kT80tKnzSV2QVZ9etqFpiYk 7qKo8kmzRaHkRPijq7NQew2ESNLZv/sx2sbuFYS7nJHe6YmNenwKN6QWGjsyBwkVl74iD/mlHcgVR YG7nblAiN3Q83PyjxkjOn1n1vXNF80E07cLRms/iteEhlpaXlSfDi5w9FtmOmd/O6MTcR7MKPA/Di 5UJC5feCnOsWWJL/8UKHmGh/Vna/hjG2loP+BVxp9iQ77DujkSAZh2bkZBcVrEqBQUeE6rrIXDRkR 3yBGhLuoUWSAOLQ5KOfg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nNb3h-005GKZ-0a; Fri, 25 Feb 2022 13:54:57 +0000 Received: from bhuna.collabora.co.uk ([46.235.227.227]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nNaul-005DDu-Op for linux-mediatek@lists.infradead.org; Fri, 25 Feb 2022 13:45:45 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: rcn) with ESMTPSA id 83DA71F4107C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1645796740; bh=Jse5jslyQwK8jYrGmsf8TVyXCyfWaI4dN1Xg9g/UKcA=; h=From:To:Cc:Subject:Date:From; b=gc1+GTNX4IdQTjOQM2VQD5ijDrvyUPUpqyrQFN0haUjKHtHW0sNDisvEDtU17qO46 bigv6hv4lf6EzHG5cLoEnnD//MUgMcFWQJQNA6pJB7qyus7PPI3jYDFa6XZUchQOsF BoUAJqJxSzl2U50ux1ZNInoIRGQ7sN8xEw9JuG3JQdokodMBPz4PK26qenZpfwRyiS BdPmG6p0EvgIyZ0iaU3W1pdk4lCqFjUd6RpScWwzbgXHbgaZgq4zFRECK+3yNvp6jI pK9lmNlAohPakmyxW8VT2umSKzX/PvIHVAom67c/lItl2j6WJXzcddmsYjtJoCaaIw nZayvxyFFqCwQ== From: =?utf-8?q?Ricardo_Ca=C3=B1uelo?= To: dri-devel@lists.freedesktop.org Cc: =?utf-8?q?Ricardo_Ca=C3=B1uelo?= , 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] Mitigate race condition problems when unbinding DRM driver Date: Fri, 25 Feb 2022 14:45:02 +0100 Message-Id: <20220225134504.457245-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-20220225_054543_984393_E377ACA2 X-CRM114-Status: GOOD ( 14.19 ) 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