From patchwork Mon Sep 9 23:20:23 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alex Elder X-Patchwork-Id: 2863451 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id E3D819F485 for ; Mon, 9 Sep 2013 23:20:56 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 27446202CF for ; Mon, 9 Sep 2013 23:20:56 +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 1C93420207 for ; Mon, 9 Sep 2013 23:20:55 +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 1VJAlC-0003Vl-31; Mon, 09 Sep 2013 23:20:46 +0000 Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1VJAl9-0004XE-Uy; Mon, 09 Sep 2013 23:20:43 +0000 Received: from mail-ob0-f179.google.com ([209.85.214.179]) by merlin.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1VJAl6-0004WO-Ps for linux-arm-kernel@lists.infradead.org; Mon, 09 Sep 2013 23:20:41 +0000 Received: by mail-ob0-f179.google.com with SMTP id fb19so6409436obc.24 for ; Mon, 09 Sep 2013 16:20:18 -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=AR9ka09KuJKcL3tsxakwqiUjTjQc0HfJdB0NQ8I3znI=; b=dENjeeNx1PV96Xfc6JMNZLAJua1FxfFXE73TEA6HERMvmrLhYIhiev+1JnwSI6Qe8H qhkY+75jk+7Ocxtgcz4z+wOAPIdR36qcxZIRF+cGzb5CgkdyKqx+dfE0TQ0lPFos8tkr T25TgCj0Wa+Ww3nkVPWKBO8Tkt0g1Zx7JGGRffLJQm4zsxyRjZhftX03If42FIkkmFls JRDtToeUK10swnpZ4dZ99+PrxoUaSPm5Mu2OHdFdem31kruLgc8OQUteyxC3D8bDsrMh 1C0mFzhLS7cTf7h5fpQkrcXhiUTjLBLQ0vBseWz4fpDCythN4GbabwMw1I9m6MLHH7ys lsNg== X-Gm-Message-State: ALoCoQmIGk3jfquuhjjzNGsgvL3gEha0OS4ryKxldgNQFbWOXaFdCbaJsv4+o9xezRX2eedv1XGr X-Received: by 10.60.45.65 with SMTP id k1mr2678810oem.48.1378768818880; Mon, 09 Sep 2013 16:20:18 -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 rr6sm16302215oeb.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Sep 2013 16:20:18 -0700 (PDT) Message-ID: <522E57B7.6010603@linaro.org> Date: Mon, 09 Sep 2013 18:20:23 -0500 From: Alex Elder User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: Mike Turquette Subject: [PATCH] clk: clean up everything on debugfs error X-Enigmail-Version: 1.4.6 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20130909_192040_863823_ECBAB808 X-CRM114-Status: GOOD ( 12.35 ) 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=-5.1 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 54a191c..727ae7b 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;