Received: by 10.192.165.148 with SMTP id m20csp3601753imm; Mon, 23 Apr 2018 09:10:18 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqovgVbWIsUInUIqJmR5BuzJAMD4pMKNWvDkH9wbGnyHfLXYDtxo7v8TFVP7PlFSH64KxVc X-Received: by 10.99.110.132 with SMTP id j126mr501809pgc.310.1524499818495; Mon, 23 Apr 2018 09:10:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524499818; cv=none; d=google.com; s=arc-20160816; b=xwrwwwJ0MYheBOnCQ3+dgtyq/xZk5QSPJxYGB3OHANsDRepUiGrUMu3Jy1szjdN6Ut 4IzicNxLpE/6qfAtlXLmP3wojSStlp/D5KlXfRbWYTlPUpJy4VNaDHVvQWjZxz1vqtrZ w6FjlQIJqzb6HV2+TRnJ6ELk3C9dKwZHUq4EQoDsEmKZQlcbo56MUhdllO80+xicd62l 7gEb0DnIBhn5o/yATel0/QCW/0SCYL4pH2G55CnYSzrKEmEkLZaYEG70ezL/Zt/GUEKg Y5KfvS2dcCGsxVvbZ7T4hGmmkn4zG5VVQFL80PuR7oeTFJEkbgr4rHGmUiZZ7VhYHeLo z2UA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=G5QcJk7Xky488ShFvGLfm4D57fhMW9QQBAHcFIQxmiU=; b=XKRwwYE5y2yijy/gzfVSpr7WChXOZl3Hz8/T8D6gfGX9KGk1qsU+H2V/f6a+Nogh2L MgcJQM5ZXIKKiIk5nPqeZlHVsQ4Rs/pNTmz360r2j2+tdoAGvJglpWSgNC+GdFaa5Pc2 fOikNlmOUELcRM+0HtFqFdRTjiCCvavN2QLlZOf+o3x+uPMquu9q+D4QwOBJ1T4g2N0F e7rP4dqcygNl9beixpD0K0bpx9AcMS3Y+kkJ45cjHuXxVHRdwDjBiIaAFs5p83NjTLf7 2s9Pel/OcQRa8JH9HCVetUhCJDIm8sF71xtDNBCXnZW3E2E3avrxGsEztMwkbEX0a+yx s/8A== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@armlinux.org.uk header.s=pandora-2014 header.b=WAyminos; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=armlinux.org.uk Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o2si4972406pgn.409.2018.04.23.09.10.04; Mon, 23 Apr 2018 09:10:18 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@armlinux.org.uk header.s=pandora-2014 header.b=WAyminos; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=armlinux.org.uk Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755700AbeDWQIv (ORCPT + 99 others); Mon, 23 Apr 2018 12:08:51 -0400 Received: from pandora.armlinux.org.uk ([78.32.30.218]:40156 "EHLO pandora.armlinux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755339AbeDWQIr (ORCPT ); Mon, 23 Apr 2018 12:08:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2014; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=G5QcJk7Xky488ShFvGLfm4D57fhMW9QQBAHcFIQxmiU=; b=WAyminosIkUgUAatqSHXdbCED 9xPRse1Xo0pHMVKgFdTy7JssoRc87YS3qaciFkMLgkbjszDXA1umkAKHIlFoTlugXe+vruuU35OaD jNTgd45CgD/l/DXFYTNUHVlRiw58g7iQ7fn1Ri5PrcoqJBL/FAxGnRSlFGvXJKdHamWKc=; Received: from n2100.armlinux.org.uk ([2001:4d48:ad52:3201:214:fdff:fe10:4f86]:39352) by pandora.armlinux.org.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1fAe18-00062w-4Q; Mon, 23 Apr 2018 17:08:38 +0100 Received: from linux by n2100.armlinux.org.uk with local (Exim 4.90_1) (envelope-from ) id 1fAe15-00027g-28; Mon, 23 Apr 2018 17:08:35 +0100 Date: Mon, 23 Apr 2018 17:08:33 +0100 From: Russell King - ARM Linux To: Peter Rosin Cc: linux-kernel@vger.kernel.org, David Airlie , Rob Herring , Mark Rutland , Nicolas Ferre , Alexandre Belloni , Boris Brezillon , Jyri Sarha , Tomi Valkeinen , Laurent Pinchart , Jacopo Mondi , dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v4 7/8] drm/i2c: tda998x: register as a drm bridge Message-ID: <20180423160833.GF16141@n2100.armlinux.org.uk> References: <20180423072301.11962-1-peda@axentia.se> <20180423072301.11962-8-peda@axentia.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180423072301.11962-8-peda@axentia.se> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 23, 2018 at 09:23:00AM +0200, Peter Rosin wrote: > static int tda998x_remove(struct i2c_client *client) > { > - component_del(&client->dev, &tda998x_ops); > + struct device *dev = &client->dev; > + struct tda998x_bridge *bridge = dev_get_drvdata(dev); > + > + drm_bridge_remove(&bridge->bridge); > + component_del(dev, &tda998x_ops); > + I'd like to ask a rather fundamental question about DRM bridge support, because I suspect that there's a major fsckup here. The above is the function that deals with the TDA998x device being unbound from the driver. With the component API, this results in the DRM device correctly being torn down, because one of the hardware devices has gone. With DRM bridge, the bridge is merely removed from the list of bridges: void drm_bridge_remove(struct drm_bridge *bridge) { mutex_lock(&bridge_lock); list_del_init(&bridge->list); mutex_unlock(&bridge_lock); } EXPORT_SYMBOL(drm_bridge_remove); and the memory backing the "struct tda998x_bridge" (which contains the struct drm_bridge) will be freed by the devm subsystem. However, there is no notification into the rest of the DRM subsystem that the device has gone away. Worse, the memory that is still in use by DRM has now been freed, so further use of the DRM device results in a use-after-free bug. This is really not good, and to me looks like a fundamental problem with the DRM bridge code. I see nothing in the DRM bridge code that deals with the lifetime of a "DRM bridge" or indeed the lifetime of the actual device itself. So, from what I can see, there seems to be a fundamental lifetime issue with the design of the DRM bridge code. This needs to be fixed. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up According to speedtest.net: 8.21Mbps down 510kbps up