Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp389605pxb; Wed, 20 Jan 2021 09:21:09 -0800 (PST) X-Google-Smtp-Source: ABdhPJxXLVCc0chJXJ56b4YnDz4I549ODrg2S0yQUO/9BRp2Rzpe/58sVNpq6nwRRbVutuj3N8oz X-Received: by 2002:a17:906:384c:: with SMTP id w12mr4416456ejc.140.1611163269094; Wed, 20 Jan 2021 09:21:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611163269; cv=none; d=google.com; s=arc-20160816; b=c60C1Y0zX7dO2mCmpRZHmCLiErMaP2XbEEh5g1K7JKnZ+QbLRhOoAZqS5eHDalUczj /z7JCC5Pfgv/NPuDhJFvBKF/z6/KTDJ2yXuamp+jkVoE9eqyz6q7OTAsIi604vmpEs2V eQhTY4f3F97sk9sL/1YcRW/u47QLO3UFxIOmjDgZWVqQCXi6k7d3hwR7JC8B9N5bWlYf dDCcrhgHrcqY3hH1xY+fUppq0LucX3veu7tKWoJzMfZkFBjrwHyzRfvRscG7C966waJN vNrSRNoh6Rk0QLiJ4NhG6DKP5pnEltVo1XDWSTW7BpVur+LpY7CdLJVt3VoSSIx5lFlZ Do7Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:cc:to:subject:from:date; bh=GgXac6M4JooQA4wOVPTVU3NCsAbNARI0xHTeah08/VE=; b=dvBU0//3/4ghvVQlPirZYW+QvVDPIbV60Dv2A6E0evMiyW6jXfQFowvLC0MOIt9itY IN7hevhPA0LJoNe5nvH0t0QWw6+V5nUm7ZcyirfTwWl0qOV+GDzNnKk+sc7kdr/U4bkp +hBQF6nArDEL0q1yJ+Yf9oKvR+Kt6WoFqUOFgX1kgfGwJ+UzXWMchJ5HXYTg/ceiU0r2 GzN76S1oLj+eJkAI5zrVBSsy8NyokBR+oEHZGADgC1nPcuTc7/qgx3A6AphCB6KYdjTY rWld8I1PpPUkoUpuJw98f0Xpt23k6VGOLoY17igH2383/vt0H+KFLXL/dXChSDu4xWOB ukVw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=crapouillou.net Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id eo9si861128ejc.734.2021.01.20.09.20.44; Wed, 20 Jan 2021 09:21:09 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=crapouillou.net Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404141AbhATRQj convert rfc822-to-8bit (ORCPT + 99 others); Wed, 20 Jan 2021 12:16:39 -0500 Received: from aposti.net ([89.234.176.197]:43934 "EHLO aposti.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2403932AbhATRNx (ORCPT ); Wed, 20 Jan 2021 12:13:53 -0500 Date: Wed, 20 Jan 2021 16:25:16 +0000 From: Paul Cercueil Subject: Re: [PATCH v2 1/3] drm: bridge/panel: Cleanup connector on bridge detach To: Daniel Vetter Cc: David Airlie , Sam Ravnborg , Laurent Pinchart , od@zcrc.me, dri-devel , Linux Kernel Mailing List , stable , Andrzej Hajda , Neil Armstrong , Jonas Karlman , Jernej Skrabec Message-Id: <4YQ8NQ.HNQ7IMBKVEBV2@crapouillou.net> In-Reply-To: References: <20210120123535.40226-1-paul@crapouillou.net> <20210120123535.40226-2-paul@crapouillou.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Le mer. 20 janv. 2021 ? 17:03, Daniel Vetter a ?crit : > On Wed, Jan 20, 2021 at 1:35 PM Paul Cercueil > wrote: >> >> If we don't call drm_connector_cleanup() manually in >> panel_bridge_detach(), the connector will be cleaned up with the >> other >> DRM objects in the call to drm_mode_config_cleanup(). However, >> since our >> drm_connector is devm-allocated, by the time >> drm_mode_config_cleanup() >> will be called, our connector will be long gone. Therefore, the >> connector must be cleaned up when the bridge is detached to avoid >> use-after-free conditions. > > For -fixes this sounds ok, but for -next I think switching to drmm_ > would be much better. The API would need to change to have access to the drm_device struct, though. That would be quite a big patch, there are a few dozens source files that use this API already. Cheers, -Paul > >> v2: Cleanup connector only if it was created >> >> Fixes: 13dfc0540a57 ("drm/bridge: Refactor out the panel wrapper >> from the lvds-encoder bridge.") >> Cc: # 4.12+ >> Cc: Andrzej Hajda >> Cc: Neil Armstrong >> Cc: Laurent Pinchart >> Cc: Jonas Karlman >> Cc: Jernej Skrabec >> Signed-off-by: Paul Cercueil >> --- >> drivers/gpu/drm/bridge/panel.c | 6 ++++++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/drivers/gpu/drm/bridge/panel.c >> b/drivers/gpu/drm/bridge/panel.c >> index 0ddc37551194..df86b0ee0549 100644 >> --- a/drivers/gpu/drm/bridge/panel.c >> +++ b/drivers/gpu/drm/bridge/panel.c >> @@ -87,6 +87,12 @@ static int panel_bridge_attach(struct drm_bridge >> *bridge, >> >> static void panel_bridge_detach(struct drm_bridge *bridge) >> { >> + struct panel_bridge *panel_bridge = >> drm_bridge_to_panel_bridge(bridge); >> + struct drm_connector *connector = &panel_bridge->connector; >> + >> + /* Cleanup the connector if we know it was initialized */ >> + if (!!panel_bridge->connector.dev) >> + drm_connector_cleanup(connector); >> } >> >> static void panel_bridge_pre_enable(struct drm_bridge *bridge) >> -- >> 2.29.2 >> > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch