Received: by 2002:a05:6358:45e:b0:b5:b6eb:e1f9 with SMTP id 30csp2099826rwe; Fri, 2 Sep 2022 08:29:29 -0700 (PDT) X-Google-Smtp-Source: AA6agR5Tte53PcordWBwTS+Kqa19/OjzIkrXYu/N9j6sux+/ZtSZEmCAK59Jxb4BtbUaH4su9bMR X-Received: by 2002:a17:902:bd08:b0:16d:4230:cb45 with SMTP id p8-20020a170902bd0800b0016d4230cb45mr35978485pls.59.1662132569293; Fri, 02 Sep 2022 08:29:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1662132569; cv=none; d=google.com; s=arc-20160816; b=pnaehPi/fS+U8wg0DT99K26s8fsoW4BI+YWS1R4xpvqYPUJwiBR0zG1RGSo6vYYWef w53+8GO0uUu22/+SzGpMg7l2BBOUmCWwbqiSFXXxEbF/vMBIhZczvnFtzYmAmC345YlB tpJiv2OrzbInE3yVteezmQIqZfx9aqbnrOutd2P5dV21dbQAwognpslj6uWEZy9o2etz Dh9bQHSZC6u8uI7yMN1AWB00RrzI/rNd+jwG2OD4DBbTDQ8MhnKZtBo32BqsOG4Q2in1 iwIeINEme23G5xblTel/XW8mjN/MFPicMKAWAbo/Qa8uB5YUFLg4QRrKAo3C+g9Uh6Ku EA7A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:message-id:user-agent :references:in-reply-to:subject:cc:to:from:date:mime-version :dkim-signature; bh=HAwDC+ZGNEoPxSWgUlrI5jj7H9smOzKu5zWicRxfk50=; b=gU+oH9eHPzapPCLsmnXyLRph/4Y+wBLClJ7Zv5WWl5ek6117urDKoUbZZhEuyam0A5 h/GUVf3ai/ORSm9nDIq4WiTmjDsHqCdjOuum+mFRBp7IUw7kCC1sjl+MeNMwXcC8YTrn gvHItiDczUIFH6RBJL0yUf+gN8J6b25p0iaa8xDU2+NR5/8NXYohOV1TUE+3vaTn+afd cs7Y7mVzpPSAIuqatsoKsx9kOkT58A8LBp9ohErtnA15Nlti7UnAR51+GioYyFkFuErg ar+n1vFD1hClk8IyvqUaQagH+D/NBstFZOxRNrSgz4ZFA+YhsMtgRkzLp/oKHzlwLYY1 D0UQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@walle.cc header.s=mail2022082101 header.b=zluc78GH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=walle.cc Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id mw15-20020a17090b4d0f00b001f4fc7af64esi8593901pjb.101.2022.09.02.08.29.17; Fri, 02 Sep 2022 08:29:29 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@walle.cc header.s=mail2022082101 header.b=zluc78GH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=walle.cc Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237034AbiIBOm1 (ORCPT + 99 others); Fri, 2 Sep 2022 10:42:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43492 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236965AbiIBOl4 (ORCPT ); Fri, 2 Sep 2022 10:41:56 -0400 Received: from mail.3ffe.de (0001.3ffe.de [IPv6:2a01:4f8:c0c:9d57::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D3F5517F6A5 for ; Fri, 2 Sep 2022 07:02:34 -0700 (PDT) Received: from 3ffe.de (0001.3ffe.de [IPv6:2a01:4f8:c0c:9d57::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.3ffe.de (Postfix) with ESMTPSA id 426D9216B; Fri, 2 Sep 2022 16:01:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walle.cc; s=mail2022082101; t=1662127296; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=HAwDC+ZGNEoPxSWgUlrI5jj7H9smOzKu5zWicRxfk50=; b=zluc78GHr8brCngTJtcQTa2rPxwNrKKDUQhKENNFnSV5m+0WfG9zhi0Ib39upNLHQw4lnp FLOtloAKdpdkLMgbV2EbEN1DrCvP4OgdPwFk69E6S1bZR1DVZo7NDbwXZIAAlSTV8ra7/i 1U1ugFa0cnnSbyTREqUTPUCVi8P57qMXyWoxK2fSFHRUI4o16BlSG2WGEbmM4iBTnvL+4r uC6/c5Xp0NZtfhBPABMwkvA0NX9k+2X1D3w1FfM7EJcOAMqGs2OEHZs0/lc3xwDVP49tC3 OzbQ7xnabN2KChxSZ4ON7e2cZOnBu1c5JeaLTS5ZL53K7vcGnfGB+9MZ55Kqfg== MIME-Version: 1.0 Date: Fri, 02 Sep 2022 16:01:36 +0200 From: Michael Walle To: Greg Kroah-Hartman Cc: tudor.ambarus@microchip.com, pratyush@kernel.org, linux-kernel@vger.kernel.org, Miquel Raynal , Richard Weinberger , Vignesh Raghavendra , linux-mtd@lists.infradead.org, stable Subject: Re: [PATCH] mtd: spi-nor: fix memory leak when using debugfs_lookup() In-Reply-To: <20220902133724.278133-1-gregkh@linuxfoundation.org> References: <20220902133724.278133-1-gregkh@linuxfoundation.org> User-Agent: Roundcube Webmail/1.4.13 Message-ID: X-Sender: michael@walle.cc Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Am 2022-09-02 15:37, schrieb Greg Kroah-Hartman: > When calling debugfs_lookup() the result must have dput() called on it, > otherwise the memory will leak over time. Fix this up to be much > simpler logic and only create the root debugfs directory once when the > driver is first accessed. That resolves the memory leak and makes > things more obvious as to what the intent is. > > Cc: Tudor Ambarus > Cc: Pratyush Yadav > Cc: Michael Walle > Cc: Miquel Raynal > Cc: Richard Weinberger > Cc: Vignesh Raghavendra > Cc: linux-mtd@lists.infradead.org > Cc: stable > Signed-off-by: Greg Kroah-Hartman > --- > drivers/mtd/spi-nor/debugfs.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/mtd/spi-nor/debugfs.c > b/drivers/mtd/spi-nor/debugfs.c > index df76cb5de3f9..3aab595e82d1 100644 > --- a/drivers/mtd/spi-nor/debugfs.c > +++ b/drivers/mtd/spi-nor/debugfs.c > @@ -228,11 +228,11 @@ static void spi_nor_debugfs_unregister(void > *data) > > void spi_nor_debugfs_register(struct spi_nor *nor) > { > - struct dentry *rootdir, *d; > + static struct dentry *rootdir; > + struct dentry *d; > int ret; > > /* Create rootdir once. Will never be deleted again. */ > - rootdir = debugfs_lookup(SPI_NOR_DEBUGFS_ROOT, NULL); IIRC I had that one and it didn't work with spi-nor as a module. Wouldn't it try to create the root dir twice if you remove the module and load it again? -michael > if (!rootdir) > rootdir = debugfs_create_dir(SPI_NOR_DEBUGFS_ROOT, NULL);