Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp3798568imj; Tue, 19 Feb 2019 09:35:39 -0800 (PST) X-Google-Smtp-Source: AHgI3IbIVLDIWoNNyUZVLYdY30+dMZILuVSGhUGV3D2FxvRUWGOlN9K8b3eKZtk6u/vfAKMwvwU+ X-Received: by 2002:aa7:808f:: with SMTP id v15mr30970438pff.30.1550597738994; Tue, 19 Feb 2019 09:35:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550597738; cv=none; d=google.com; s=arc-20160816; b=fJK793GcSpMFE9h+sC//9NyYWs8JM9tK50eraPB/lyhkCUDIyQO5VWjfPGLeW+aRRi 95j03dXklJQsPLFbmYKz4E9D90k/krWj1I6w7eAl8mbnPZvBE4SvgIsOMqkpWHTYowsl eciPQxrVMwXfcBQK3sf7DjlGmI7JGFZYQhJp4iaOOCGcPqnqn8JI4g7CD3G+/LyxnQXH CQdRzaJlW+JELCjw+trKfej/AvGqYNtnasZlZFFXwzHAAnFt213///gfAgo1F/8Ljnvg +ydVt+X9Pm3gi9Epz+GZoSnk5oVxXAku66y/1WwiKJltEoAsdexzo3+1eolUBpqkwTsS CaFw== 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=MMx5A9b7K7yk9d7COi0Fp7lpPyFSTes5TSyV7oDQCUQ=; b=OvlpQs42XuVI+Q/YceeGzfOm/zSvaBoP7ilk3Lwa5R7EVxAqIWzS6+JjHxNKTsv8fA BnSGWKGNZLBR+2fZXZWXi2NHNi9aoc9+UkRrN8GHy7Wm90ltlDXXhln68UxJXINkaxyF o7ahGxRpeddf3k9PFgizcfR0yi4oFRtrVJgkxLA8pd4x6CGDtyZYNF/m3z8JtxUEL6qx e75qL9zLZQbm1iEWIyNMgnosx12BBuB4nuP2nU16he/jnveDfLJXo5+LVrLcglmmRZl5 rlYrZw02MGerNKwToum5QWzULjyiuvoOuKwz2dICDnC6VmsIabq4Ah/dCTqwVj+mDQah Fxnw== 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 x14si13343268pgh.98.2019.02.19.09.35.23; Tue, 19 Feb 2019 09:35:38 -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 S1727957AbfBSRd1 (ORCPT + 99 others); Tue, 19 Feb 2019 12:33:27 -0500 Received: from mail2-relais-roc.national.inria.fr ([192.134.164.83]:20118 "EHLO mail2-relais-roc.national.inria.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726321AbfBSRd0 (ORCPT ); Tue, 19 Feb 2019 12:33:26 -0500 X-IronPort-AV: E=Sophos;i="5.58,388,1544482800"; d="scan'208";a="370069650" Received: from vaio-julia.rsr.lip6.fr ([132.227.76.33]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Feb 2019 18:33:24 +0100 Date: Tue, 19 Feb 2019 18:33:22 +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); > if (r) { > ... > } > > If so, Julia might have a Coccinelle recpipe for it? Unfortunately this is not really an ideal case for Coccinelle, because node is the result of calling a local function and Coccinelle doesn't by default do any interprocedural analysis. It is possible to write a rule that explicitly looks for one function that returns a device node and then the pattern of its usage in the caller, though. julia