Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp742378imm; Wed, 10 Oct 2018 03:40:45 -0700 (PDT) X-Google-Smtp-Source: ACcGV63+RVVwNX+62ciOVYHxQKd48xOKGXYa7YoR6xGrlKYKpgNdkyDxlk7tHBZ70kzeBziKccIk X-Received: by 2002:a63:6a86:: with SMTP id f128-v6mr29672935pgc.165.1539168045592; Wed, 10 Oct 2018 03:40:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539168045; cv=none; d=google.com; s=arc-20160816; b=mAfnvDVteut8Mn/ZuHPUZc1pdy0GB2wX42rZeFOlDncAme0+jVbX/78uT0tMwrJzVc DwRj0EoKZUaeYmAyfnHkmngOhG2SN59XKHwZZF6D1Alb8lDAc2K/503qVzAuzZP0gpI/ bNy/TM57tDOqDSt1JjiU9+3hH0uLGckjR0mqjxmEYmohpljmcPOVmyY6iHxrqoFr8JSN Y0ixOb0eKhEFtKSa11s8R1Vc1roO0/5+lhYKJyB+PKuQ7WIh5M0xXn+C3XDFwmvjpk/h c42/wH07gC86YveY7uoVpoE08JW/W4FtyWeb/K6Vjyn3K0LD9UsMVsgC6CdKcML4Gz6y gt7w== 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; bh=ODn6CSKedcw5RWj+VDJe64GPsn7ondlBdtqLXyCzepg=; b=gnc6WfBY6wHXzPPEnmUynTOyKl/9z+5XXKxRo2cu8OK4WXrKV/xQfjHdrZVaKldW2G ZUvSjOzv5pOPHxEpUu1W1ze3WjyvCcVeaFBNW02zB1ElRIV3l28bj24wIeKthzC3CiPi 8RxIxndClL3naVowiYKaW/Nas5tfYWy4iG6e3yg4y5OiuN/EYklGJyb6qgx6ED22Wv1f nQwPZHnTeigH7sUUF5Yle6c3y18xuZzNr4ynEpB+bu3jowo6RjqAGcEb+DjflroD0QQg DP3LPYsZxjLhFAk4B3QEm/Pu1FkPz+15QbXagXjv3QpMcd/u521QTjUMdeSMXM+tKgJV pIPg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@armlinux.org.uk header.s=pandora-2014 header.b=H++l1mfS; 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 r144-v6si30303164pfr.100.2018.10.10.03.40.30; Wed, 10 Oct 2018 03:40:45 -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=H++l1mfS; 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 S1726731AbeJJSAQ (ORCPT + 99 others); Wed, 10 Oct 2018 14:00:16 -0400 Received: from pandora.armlinux.org.uk ([78.32.30.218]:46560 "EHLO pandora.armlinux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726479AbeJJSAQ (ORCPT ); Wed, 10 Oct 2018 14:00:16 -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=ODn6CSKedcw5RWj+VDJe64GPsn7ondlBdtqLXyCzepg=; b=H++l1mfSF/CcQRJHrl0k0wqiS 0xZQHwbLCdrqmMlAg4NrstV0SN616BRfNwfnO3mSKD/ayV3hddLqgxVpsUNV3nPGkhqRsVk7e7Q9y LI6cbN5Ri60zwWvx8qc8YVhWmp2lPcxpkq93HpsWt9tgPrvVoJeFsG4jEuy//NdosnSYk=; Received: from n2100.armlinux.org.uk ([2001:4d48:ad52:3201:214:fdff:fe10:4f86]:58239) by pandora.armlinux.org.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1gABsw-0006DT-2t; Wed, 10 Oct 2018 11:38:34 +0100 Received: from linux by n2100.armlinux.org.uk with local (Exim 4.90_1) (envelope-from ) id 1gABst-0000le-1a; Wed, 10 Oct 2018 11:38:31 +0100 Date: Wed, 10 Oct 2018 11:38:29 +0100 From: Russell King - ARM Linux To: Stefan Agner Cc: p.zabel@pengutronix.de, airlied@linux.ie, gregkh@linuxfoundation.org, rafael@kernel.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] drm/imx: make sure to cleanup DRM before unbinding components Message-ID: <20181010103829.GN30658@n2100.armlinux.org.uk> References: <83a28282a3f745a4cd4ca77d0593ad2e61359a5d.1539120077.git.stefan@agner.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Tue, Oct 09, 2018 at 11:30:49PM +0200, Stefan Agner wrote: > In situations where a component fails to bind, a previously > successfully bound component might already registered itself > with the DRM framework (e.g. an encoder). When the master > component then calls drm_mode_config_cleanup, we end up in a > use after free sitution. > > Use the cleanup callback to make sure all framework level > cleanup is done by the time we unbind components. I'm not sure about this approach - the idea about the component bind and unbind callbacks is that unbind undoes _everything_ that bind has done, so everything is correctly ordered. If bind registers something, unbind should unregister it. What seems to be going on is that imx is registering stuff in bind() but not unregistering it in unbind(). Since imx was one of the drivers that the component helper was created for, if it's now crashing, that's a regression in the imx driver. Looking at the commit log, I'd say: commit 8e3b16e2117409625b89807de3912ff773aea354 Author: Lucas Stach Date: Thu Aug 11 11:18:49 2016 +0200 drm/imx: don't destroy mode objects manually on driver unbind Instead let drm_mode_config_cleanup() do the work when taking down the master device. This requires all cleanup functions to be properly hooked up to the mode object .destroy callback. Signed-off-by: Lucas Stach Signed-off-by: Philipp Zabel is probably responsible for introducing this problem, since the explicit calls were added by me when imx was stuck in staging due to the problems that the component helper solved. I think what we have here are different opinions on how cleanup should be handled. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up