Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp3794030imj; Tue, 19 Feb 2019 09:31:10 -0800 (PST) X-Google-Smtp-Source: AHgI3IYKBwXPP/oOC7lXWRcjOPBgO35W68l934Xl152hf/eL7qDdKKaLEkeJx0ZXRCZymkKApwZl X-Received: by 2002:a63:28c1:: with SMTP id o184mr10798171pgo.123.1550597470488; Tue, 19 Feb 2019 09:31:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550597470; cv=none; d=google.com; s=arc-20160816; b=LEcBnCaLlXxldDdvTvhioLw3yfiykGf0OeYNl6PtDwPS1ynyO4dSIZp0KOiTABt0gc JeOJghp4QXAoEn3+P+IGQ5QG5R0w2kQlvKfFDUo7Ji/eyIxR5O6lwOqdWoqu4QZvU7TR /eIMwvg3h+omxZwG69q8RYKWiZiNERSRrICjgbaoum3ZY7KD0SsBB6LxCZG2E5LP4Mdi mmI99k6MvBrW9LX2oB8Wn0/sSOrLhWgDpsO+be9rRY/DUHI1TuVfntY5eOGCaWz7KqN+ woTBDPBWj1QJeguu4ad5mXCKGv99N9dS6LhWQwkgYjNzdKhwIxthA92L68UzktzfzjRF 1odA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=2N1NYLI7o6gDLhb8KSGDZmwmzAlJBL06LfYgPVOqSKU=; b=Lw/CxNea0/NdNt+ORCQTNPAL6rW/C1bc6ujZuyi2In/pTwClBS83aOiep00gfIErTC 6x7/AMxkdXockkcXBQimItIGplTU5fWd/T83JqX9ciRa/BpkhyzEC76+vS+DGV46Nt79 b42IqPJCYnDHeIOO7sJb8Dh3iVy7trbCRKltFT+YY037V7TXlYCcNDLBHMvxpBK43KPZ w7OSaKQxYhmJH2PPmj1jDWJmHFqPesnLftnUSBGAgNDyhqDmt/ziBtjVga4X+H67MWO3 CfHkNOgF7KA+xMvHFkLAVC/7ys9Nph2a5HKKsnJLpIv9B+oPgvZPOYx4AXnatvYX7Sqy DRTw== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i68si17639819plb.325.2019.02.19.09.30.53; Tue, 19 Feb 2019 09:31:10 -0800 (PST) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729069AbfBSRaS (ORCPT + 99 others); Tue, 19 Feb 2019 12:30:18 -0500 Received: from mail3-relais-sop.national.inria.fr ([192.134.164.104]:15427 "EHLO mail3-relais-sop.national.inria.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725613AbfBSRaR (ORCPT ); Tue, 19 Feb 2019 12:30:17 -0500 X-IronPort-AV: E=Sophos;i="5.58,388,1544482800"; d="scan'208";a="296689475" Received: from vaio-julia.rsr.lip6.fr ([132.227.76.33]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Feb 2019 18:30:06 +0100 Date: Tue, 19 Feb 2019 18:30:03 +0100 (CET) From: Julia Lawall X-X-Sender: jll@hadrien To: Tony Lindgren cc: Peng Hao , linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Tomi Valkeinen , Rob Herring , devicetree@vger.kernel.org, wen.yang99@zte.com.cn Subject: Re: [PATCH] arm/mach-omap2/display: fix possible object reference leak In-Reply-To: <20190219170516.GL15711@atomide.com> Message-ID: References: <1550071969-86286-1-git-send-email-peng.hao2@zte.com.cn> <20190219170516.GL15711@atomide.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 19 Feb 2019, Tony Lindgren wrote: > Hi, > > Adding devicetree list, Julia, Rob and Tomi to Cc. > > * Peng Hao [190212 23:11]: > > of_find_device_by_node() takes a reference to the struct device > > when it finds a match via get_device.When returning error we should > > call put_device. > > > > Signed-off-by: Peng Hao > > --- > > arch/arm/mach-omap2/display.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c > > index f86b72d..c6aa9ed 100644 > > --- a/arch/arm/mach-omap2/display.c > > +++ b/arch/arm/mach-omap2/display.c > > @@ -258,6 +258,7 @@ static int __init omapdss_init_of(void) > > r = of_platform_populate(node, NULL, NULL, &pdev->dev); > > if (r) { > > pr_err("Unable to populate DSS submodule devices\n"); > > + put_device(&pdev->dev); > > return r; > > } > > In general, if the device tree node is never used afterwards, > should this be just: > > r = of_platform_populate(node, NULL, NULL, &pdev->dev); > of_node_put(dev_node); Are these solving the same problems? The of_node_put looks clearly necessary, whether there is a success or failure. I'm not familiar with put_device. I see that it does a kobject_put, but I don't know what happens because of that. But it looks like an inconsistency that Peng's patch only considers the failure case, while your suggestion happens always. I guess Peng's patch is motivated by a Coccinelle script that Wen Yang (also from ZTE) has been working on. Perhaps there is a need to adjust what is suggested by that script. [Wen Yang added to CC] julia > if (r) { > ... > } > > If so, Julia might have a Coccinelle recpipe for it? > > Regards, > > Tony >