Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp2053460rwb; Sat, 24 Sep 2022 02:03:17 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5ZAifch7Z8IJnaDJYFQqkVcLC0XMHxnptMzUXoeDo3uQq+tpR/yKzUQVozk/lYVq9Ll385 X-Received: by 2002:a05:6402:510f:b0:451:624f:2f02 with SMTP id m15-20020a056402510f00b00451624f2f02mr12317090edd.40.1664010197527; Sat, 24 Sep 2022 02:03:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1664010197; cv=none; d=google.com; s=arc-20160816; b=XrzZAQQw9XkSQy+xN4KMJFKxOXFRnIY1iLttF+d6oMqm1kKSR8yrNzK8vH29sGHpMU jWoWf9HnTFDOdlueceN38wAa+SR+xVckiA8PLEZ3W/7NVOItvs1p+aTX8aLVDEZZlJB/ UEmSsuMfaNxBwwBlsi7fLOJFJsv8sYFYPDTVhdmc8QKnSmmK+cmvWd2k50+J7l86WFdB rgx1r4oEK3sd5sShxRCCoTY3PTGp4loLsvHuHFHIGMMmSLnt0qe2qcBMHJjt8bzFiWqB /EOA5eC7mic2JXi525bDlERJoToqjdjazOBwDk248PQHne1cR6gTjF5NsXbXjWzncGDG n/ow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=1ZaqLVJbi+LBx2xpHSS/X8x4XHStLx1bhtp/EQAZd7U=; b=fXWhruYeTG7eSIasNDylBrCXLTJOAhPEfDTRSovg5GnpenptkyhNbvmp/tBmbmroxW pCwTnW73lPnNi0/fpVaDfct2VBjSKcqVZu8gUhEWfvlj2Z5oX5ZDZ/vM7aYPGvNsUNYx 81V1I7Y3kNJ+ES/LVlMSX9SC2I8LivKRjPYRIXGlUwJY/h9agZct9oPno9rhkpPZTrXa 0Icd3L275DVb9AreCA67OZ421GtE+5EAHCLqeIlNO4rPoZUgj/8wAptUKAiith2kLboL mH22rWCGWwkOaOQ+qw2zARenGQUS90tQKQbfVziTSf9kYOR6QbTanbzR6T2BcpCxbOyM LTKQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=UcHsy0do; 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=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id sb2-20020a1709076d8200b0078212b2e6e2si82393ejc.75.2022.09.24.02.02.52; Sat, 24 Sep 2022 02:03:17 -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=@linuxfoundation.org header.s=korg header.b=UcHsy0do; 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=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233501AbiIXIq2 (ORCPT + 99 others); Sat, 24 Sep 2022 04:46:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35626 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233484AbiIXIq0 (ORCPT ); Sat, 24 Sep 2022 04:46:26 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BE3AADB969 for ; Sat, 24 Sep 2022 01:46:25 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 5D925611C1 for ; Sat, 24 Sep 2022 08:46:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6B163C433C1; Sat, 24 Sep 2022 08:46:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1664009184; bh=CcEEfEzmwgcNfVrRYjABgYWLl6nWS4p/VMRs14C4hro=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=UcHsy0doGginUWgjwPxrp/H3kbhKcR4wIR9uNQQ/y2NSfOaAbIxgWKy3EwT603iED XY9RVIObc13AtgwD7/bwikbPyhbB/B7t20TyA76f+9S1iEq09XNdt0HD2auwzdUQWI lNXIAUeSSq5oAi55bY0bEi9xg75LB4+61I0PW+uU= Date: Sat, 24 Sep 2022 10:46:22 +0200 From: Greg Kroah-Hartman To: Michael Walle 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() Message-ID: References: <20220902133724.278133-1-gregkh@linuxfoundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS 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 On Fri, Sep 02, 2022 at 04:01:36PM +0200, Michael Walle wrote: > 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? Yes it would, that is a use-model I did not consider at all, thanks. I'll rework this. greg k-h