Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp21692pxf; Wed, 24 Mar 2021 19:36:19 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyMDLF4M+CQKwHej/HUlQ1d8LUzfS3B9TiCjZR8sAvH1Jh6uuEsLVA4WbpxCZ2EnnXIn6Zb X-Received: by 2002:a17:907:3e8a:: with SMTP id hs10mr6986226ejc.267.1616639779524; Wed, 24 Mar 2021 19:36:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1616639779; cv=none; d=google.com; s=arc-20160816; b=vmi6g0IMAd3ENnevS4kEWd1MSKWAwZ4p//bkpqSre1vIoOKkt6gB07lWG0gSoolNMR obaitMSBu2USV1ep3sO/aJOU7LFLSaiGyb6vJoNcgnv/Q+abTdoe3q665Y9cbi0isqFY aea3EyIbOifQCxd+cN+NaSeOeh/7w+dac6CbvUrKWLIpCRxzTX3YInJRSwJuUNNidRDp CsWnRxiqGBUeo0TBldifHF6Or1wHG/RQp1buqgdtGFd9Q5yDNiVnjA/ldicXBdwUD+f4 Fd7+nXTxml8Drz2ZcBpSNLHM4uF5M5G0xIYfpFLAHVZIVikY68BzP5DgBu5WmH3JpDvE sXOw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:mail-followup-to :message-id:subject:cc:to:from:date:dkim-signature; bh=+spcrwNB5vbrwaK4T0mml0SYdMYl5UpR9KJiaTQ0lDk=; b=Xp3e+JkBUJNGmSF4/2VC9U7m8W9Kw2dKEl5KJ5cz+JLY8Tjj8dmi+mSouvBpPexBeA pNI06nCgLqqboSVMuvrnnNp6ivbBoo2DSo9vqRmwRvOqUG4EnAGZdCk9hi3gWNWrkrWB d7o2xbDVF5YFyfz7mfFCQaXQzDkLhq2kC0H3EcZmmswMTuUWTBgvCLp33acjadNQ9nBc 7LLiBSqWX31QDRGNgLmm92+TGO4jgNeYKzWd57qR0aPyD1ccnMGvhdFSg5FAeTbihMXA WuVbp61ur1lrasAqmdh/gS9g4VPVu9xx2i9Y9juxIhuwAI4LEWPHa/rTAafRjK23thvr itew== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ffwll.ch header.s=google header.b=cHUmoWG6; 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 pk25si3294194ejb.402.2021.03.24.19.35.56; Wed, 24 Mar 2021 19:36:19 -0700 (PDT) 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=cHUmoWG6; 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 S236160AbhCXJkK (ORCPT + 99 others); Wed, 24 Mar 2021 05:40:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43342 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236277AbhCXJkC (ORCPT ); Wed, 24 Mar 2021 05:40:02 -0400 Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 993ACC0613DE for ; Wed, 24 Mar 2021 02:40:01 -0700 (PDT) Received: by mail-wm1-x32b.google.com with SMTP id t5-20020a1c77050000b029010e62cea9deso807686wmi.0 for ; Wed, 24 Mar 2021 02:40:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=+spcrwNB5vbrwaK4T0mml0SYdMYl5UpR9KJiaTQ0lDk=; b=cHUmoWG62TuScphZQB1TRRPDN2v2lIKj7c+zPMqbUsVUCGF7azyokxzZftv9qkhhKv QCjAwskEi3J2ie/fdV8XhL5rtyev+MtTWZn7FrIQT2yjBT2buSJEZYxoMQGmDOP/8CP9 BLTD7RlnMgpijdsr1yLDiqQGewX5ZnDeL4Fqw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :content-transfer-encoding:in-reply-to; bh=+spcrwNB5vbrwaK4T0mml0SYdMYl5UpR9KJiaTQ0lDk=; b=BSmxFBDXMtHNoyaunmFtV4710acKqPQiNkEObMAaUgx3I3PjHakk642dFT/dWNl3np Sc4aK7VF5047/7EzXynnuVK6zaAPZ9PniVX26T9UlKhouDrah9MtAjZ1CA1uw3HUSF2t 5J9VOAqGx5j2g+OXtiOAHplMigqA/i2Kpy7NpZ0VAFv9oLAIFFUL90HA3KTRIR30pMfA 9EKDf3ttip56Jx4Yllfjn4PsBAjUdXq/3+F6wNd4lcJYi/QU7cp7qTHXTWAQFdAHjVaH S4Z3y3JoI2/WOR4M13HT2XLqz+yp+h0NOSNokpmLyiEqRL1eSEgsi0l8EFpJz3JbmPl8 0muQ== X-Gm-Message-State: AOAM533snjOFB2KiraC589PMn0i5vwPJYCVvhJY639j/aBw64Pu7bNgY 4lqFwkiC4HqQOPHGBQ8K7j2RaQ== X-Received: by 2002:a1c:3d8a:: with SMTP id k132mr1971366wma.71.1616578800309; Wed, 24 Mar 2021 02:40:00 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id l1sm754850wrv.87.2021.03.24.02.39.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Mar 2021 02:39:59 -0700 (PDT) Date: Wed, 24 Mar 2021 10:39:52 +0100 From: Daniel Vetter To: Laurent Pinchart Cc: Daniel Vetter , Paul Cercueil , Jernej Skrabec , Neil Armstrong , David Airlie , Jonas Karlman , Linux Kernel Mailing List , dri-devel , Andrzej Hajda , od@zcrc.me, stable , Sam Ravnborg Subject: Re: [PATCH v2 1/3] drm: bridge/panel: Cleanup connector on bridge detach Message-ID: Mail-Followup-To: Laurent Pinchart , Paul Cercueil , Jernej Skrabec , Neil Armstrong , David Airlie , Jonas Karlman , Linux Kernel Mailing List , dri-devel , Andrzej Hajda , od@zcrc.me, stable , Sam Ravnborg References: <20210120123535.40226-1-paul@crapouillou.net> <20210120123535.40226-2-paul@crapouillou.net> <4YQ8NQ.HNQ7IMBKVEBV2@crapouillou.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: Linux phenom 5.7.0-1-amd64 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 24, 2021 at 04:15:37AM +0200, Laurent Pinchart wrote: > On Wed, Jan 20, 2021 at 06:38:03PM +0100, Daniel Vetter wrote: > > On Wed, Jan 20, 2021 at 6:12 PM Paul Cercueil wrote: > > > 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. > > > > 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. > > Bridge removal is completely broken. If you unbind a bridge driver from > the device, the bridge will be unregistered and resources freed, without > the display driver knowing about this. The lifetime of the drm_bridge > structure itself isn't the only issue to be addressed here, it's broader > than that, and needs to consider that the display driver could be > calling the bridge operations concurrently to the removal. So for the "unloading bridge should first unload display" problem that was supposed to get fixed with device links. There was at least a patch for that, and I Rafel from pm side did all the core changes to make it work. But it didn't land I think, so things keep on sucking. Ofc the lifetime of the bridge structure is then an additional problem on top here. > We need a volunteer with enough motivation to solve this subsystem-wide > :-) In the meantime, whatever shortcut addresses immediate issues is > probably fine, as yak-shaving in this area would definitely not be > reasonable. I guess drm/bridge keeps on disappointing :-/ -Daniel > > > > >> 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) > > -- > Regards, > > Laurent Pinchart -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch