Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp452571pxb; Wed, 20 Jan 2021 11:00:43 -0800 (PST) X-Google-Smtp-Source: ABdhPJxY00Lsm4OhRV0GQb1iLR//jBuy9RxwpqMPCR09Ba3tdd0GtrcLhuJHGQQE8YGLGfCyvcG1 X-Received: by 2002:a17:906:60f:: with SMTP id s15mr6313685ejb.25.1611169243470; Wed, 20 Jan 2021 11:00:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611169243; cv=none; d=google.com; s=arc-20160816; b=smwy1zmeq9o3vYLzsj3LPmJXt2YD3Xqfv70PovBRmQE9TUSe9GDZLSwI0NbS+mjPKN ImX5pz0MgsWfJKIdKF3yto62o2B//UdZMGN4/xpr4RPMWibx8jQW7He8etvYLFp6Qzg1 LmuMhXsxiN99zaC2dy96MTWGmlbLflAcn5q1AwM1CfAze3GwvvA39dzVRo+MWivKewiM XHXiaggJZ8zL0en6tuW+j0GP+UuK4MXHPImIBJ1IDERen5R5RwKWzbXu4ji03EwJlwgD +L/Fq5HP9XMYNME3uQe9GBv2V2zkefteKXpeiRY++2pldQjP1FdvmsTuNOzBIPq0szok Um9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=MNhh3DZneZFVWfjxYIARFu1yzUnEDm7HphLodqo3DQk=; b=uWf7PN09K6B+YVMQ8uedfkLDfRUkHHvEx7eXcGmkVmytw/YHfBfFq7d98BehPE1jEZ fJNDKJdkIZPw3opgsBwk05Nj15RcVFOh4IPM8YYTZZB99qiWikRZ4RsVpORjZV+9uJR1 kGtNwOOYtZDCXFpGjHCp93O6ZSUPBhS1ESdBVPI5keChKg3h/qmA4KU6GZqgNMSR+AQW UlvN9jUUSFvuVj0GZexBNsTHB6P5JENpLvWyQ4iexYQgbXLp3qUiOLJVxpu9m780vGbI 3lTNUCFpgc3t6GmcphsXJK/6ExDdsOx65RLhF+GTECaOyhHVs2Z9pgy5voPgVNmk+Izi OD8Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ffwll.ch header.s=google header.b="b3rRh/jJ"; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g1si952470ejc.697.2021.01.20.11.00.17; Wed, 20 Jan 2021 11:00:43 -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; dkim=pass header.i=@ffwll.ch header.s=google header.b="b3rRh/jJ"; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2392316AbhATS7l (ORCPT + 99 others); Wed, 20 Jan 2021 13:59:41 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37376 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732853AbhATRi4 (ORCPT ); Wed, 20 Jan 2021 12:38:56 -0500 Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D7474C0613ED for ; Wed, 20 Jan 2021 09:38:15 -0800 (PST) Received: by mail-ot1-x329.google.com with SMTP id a109so24168349otc.1 for ; Wed, 20 Jan 2021 09:38:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=MNhh3DZneZFVWfjxYIARFu1yzUnEDm7HphLodqo3DQk=; b=b3rRh/jJExyI8+DPE2UALXm6/mFfCwwF0E489at7YF/FdDDs0G59cic92B9HOqPYkn i6Ke9a/H8crN4utU/49/HEC+QiHzShWj0IbERe//iYPc/9zNyUUpHrEorXkfeSdsJ1j+ ioxRKAxIg8/yTdUpMKiCa5gZBnHCO8HcDx4+M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=MNhh3DZneZFVWfjxYIARFu1yzUnEDm7HphLodqo3DQk=; b=ON6Yq0rlzfj6Bs54VTayY1p8mqJUl66hWAZg/GhTsIJUMpwqJRbu4LdZAtLtTxjskb AMOfij3pIdZDXgU3df7Yrue0jUf0XRVO/xms+XJNK61kZqgj7nAVL7Q+hk9tP1D16yGU Y4LqEJEsb6empVKYDI69b49k4wSfjw5iBDWsvx9LmcxOCR/z8gliOzN5LLIiPuXoNCLs RJ9xGZKMPWEjTDetQZ2iyACeTj/FTnvu3ERPCz8VFeLiT51S6a+4ciR+n6V+bA7Nl1BI MsSrD0tQG32oxbZd4DWlNXS6vm/vW3xopIs6uREL+PBag6H/vZZjR6YfWnWB91SPyayl /Oqw== X-Gm-Message-State: AOAM532cbR1GG/t2Ci4xgiL1+k7aIJ8kSMuGndILrflSsdZCZD06QSIV sPeP8aTVzb2MrI7nm5QviUy+JsfyvfiYNaxb36GFpQ== X-Received: by 2002:a05:6830:1bef:: with SMTP id k15mr7621513otb.303.1611164294761; Wed, 20 Jan 2021 09:38:14 -0800 (PST) MIME-Version: 1.0 References: <20210120123535.40226-1-paul@crapouillou.net> <20210120123535.40226-2-paul@crapouillou.net> <4YQ8NQ.HNQ7IMBKVEBV2@crapouillou.net> In-Reply-To: <4YQ8NQ.HNQ7IMBKVEBV2@crapouillou.net> From: Daniel Vetter Date: Wed, 20 Jan 2021 18:38:03 +0100 Message-ID: Subject: Re: [PATCH v2 1/3] drm: bridge/panel: Cleanup connector on bridge detach To: Paul Cercueil 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 20, 2021 at 6:12 PM Paul Cercueil wrote: > > > > Le mer. 20 janv. 2021 =C3=A0 17:03, Daniel Vetter a > =C3=A9crit : > > 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. Hm right pure drmm_ doesn't work for panel or bridge since it's usually a separate driver. But devm_ also doesn't work. I think what we need here is two-stage: first kmalloc the panel (or bridge, it's really the same) in the panel/bridge driver load. Then when we bind it to the drm_device we can tie it into the managed resources with drmm_add_action_or_reset. Passing the drm_device to the point where we allocate the panel/bridge doesn't work for these. I think minimally we need a FIXME here and ack from Laurent on how this should be solved at least, since panel bridge is used rather widely. -Daniel > > 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 =3D > >> drm_bridge_to_panel_bridge(bridge); > >> + struct drm_connector *connector =3D &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 > > --=20 Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch