From patchwork Wed Oct 9 18:47:47 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alex Elder X-Patchwork-Id: 3011301 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 76B23BF924 for ; Wed, 9 Oct 2013 19:03:06 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 59C44202C7 for ; Wed, 9 Oct 2013 19:03:05 +0000 (UTC) Received: from casper.infradead.org (casper.infradead.org [85.118.1.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 139E62026D for ; Wed, 9 Oct 2013 19:03:04 +0000 (UTC) Received: from merlin.infradead.org ([2001:4978:20e::2]) by casper.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1VTyur-0007fi-OZ; Wed, 09 Oct 2013 18:55:26 +0000 Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1VTyu3-0005Sa-CN; Wed, 09 Oct 2013 18:54:35 +0000 Received: from mail-ie0-f172.google.com ([209.85.223.172]) by merlin.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1VTyu1-0005RI-7e for linux-arm-kernel@lists.infradead.org; Wed, 09 Oct 2013 18:54:33 +0000 Received: by mail-ie0-f172.google.com with SMTP id x13so2858343ief.31 for ; Wed, 09 Oct 2013 11:54:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:content-type:content-transfer-encoding; bh=2bPBUmy9RcOiYe+Or331VJbw/UKXXyi2H4+5JCSdjTM=; b=bqN4JhP0/PV76rXgwo1v/SsGrdQzKGhvUQwj1F2Av9N/t3pZxQH582mWeNocPXxU5E l+W7/QnJQ5RJJCt4nw6p15YvnXVYiW7xxYyCn6Rfx/1t/NjhKPRva5l4rDod2+sbsIit qX6l/KI2PnE1zlRwsXe7BxfsSH+LOGcZmRlGYr3nwp/tbSVVmcl8Uqlv4m1Jndv845ed KGtRsfD4JXoSzWuzjopesk+ExvNxpjRgo637UigTi8pdA0+vy5mvfbBaWnOcgwc+Ke2k wavnp//GOW8gZAjxt4koHgysSBR4BTlrsrBz8gGJpANfg+86KI7gt6MVyLd4BS6PvYyV bW/Q== X-Gm-Message-State: ALoCoQmsfHP+12QX9vg1XCMNdcwhEuiBy70I6S7cie20y4fiHjymfMyf6iOKqiwbe5zKZTPqFYUc X-Received: by 10.43.178.135 with SMTP id ow7mr5441088icc.43.1381344444194; Wed, 09 Oct 2013 11:47:24 -0700 (PDT) Received: from [172.22.22.4] (c-71-195-31-37.hsd1.mn.comcast.net. [71.195.31.37]) by mx.google.com with ESMTPSA id ka1sm9060562igb.7.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 09 Oct 2013 11:47:23 -0700 (PDT) Message-ID: <5255A4D3.5030701@linaro.org> Date: Wed, 09 Oct 2013 13:47:47 -0500 From: Alex Elder User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Mike Turquette Subject: [PATCH RESEND] clk: clean up everything on debugfs error X-Enigmail-Version: 1.5.2 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20131009_145433_305430_C06EA4A3 X-CRM114-Status: GOOD ( 12.18 ) X-Spam-Score: -2.6 (--) Cc: LKML , linux-arm-kernel@lists.infradead.org X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP If CONFIG_COMMON_CLK_DEBUG is defined, clk_debug_create_one() is called to populate a debugfs directory with a few entries that are common for all clock types. If an error happens after creating the first one debugfs_remove() is called on the clock's directory. The problem with this is that no cleanup is done on the debugfs files already created in that directory, so the directory never actually gets removed. This problem is silently ignored. Fix this by calling debugfs_remove_recursive() instead. Reset the clk->dentry field to null afterward, to ensure it can't be mistaken as a valid pointer. Signed-off-by: Alex Elder --- drivers/clk/clk.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) } diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c index 2cf2ea6..77fcd06 100644 --- a/drivers/clk/clk.c +++ b/drivers/clk/clk.c @@ -272,7 +272,8 @@ static int clk_debug_create_one(struct clk *clk, struct dentry *pdentry) goto out; err_out: - debugfs_remove(clk->dentry); + debugfs_remove_recursive(clk->dentry); + clk->dentry = NULL; out: return ret;