Message ID | 20230208160230.2179905-1-gregkh@linuxfoundation.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp3540475wrn; Wed, 8 Feb 2023 08:07:39 -0800 (PST) X-Google-Smtp-Source: AK7set8WwkHdqm/v3ztmxM7hErXi3PSRSRBR+/jVaDlzoaYvoXfteqkR4VoRgaxkOBQxVAAoPMee X-Received: by 2002:a17:906:283:b0:89a:8238:3323 with SMTP id 3-20020a170906028300b0089a82383323mr7258936ejf.6.1675872459287; Wed, 08 Feb 2023 08:07:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1675872459; cv=none; d=google.com; s=arc-20160816; b=eNxT8n/gM4BvFcONxKszGkeSIJ528bXe2YP27oFZBJpGlBP1YhED4u3bgcmNJO8Faz 08SZ9OJYQ9UUvhAgLUiryAov0ZQqGE3KX8zzrNQI2xV+VnZB+dxS7r9e2PlUsQkP5xcz /A9Ctasfqr3VooeOOyG+dTs4pMXMiXSRGDddTDiXcQvFOgJFAYt9W119vRpQ3vxVLOoA J8R3T9Xh/kKesV7yDG9D1vEgA29mS55YQePSeI67aL0bfBet6LO7wG+ZiZ++9FwiO61T Hn+41LfMKTGdIW7QwVBAuu3m5AS7dqEA8XSt5uVq57yrdqJEnIl1gTuYMFx2daV+o9yF VCXA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=xt1R12knjqn1ZEbW4I2qoH86sUebORdrZc5Z/i6P1hc=; b=VxM4h7GiVkyCyJibSIY0DjVIxdDMGC/IST5X4ZFGdZg2/Cx5bubs7qpmPfpCh3umTH vyVcOUkS0hvzuJR9R4xb05WJpFDW+EtWh37LASNrORvNSXXBaPuBG9zbg72Wfe/osfit G0+sy5Sb4LHLTH0iCxpjUvLYyQDLNgsWKKq7Mo+182W7tFH59XSFWdjiXYcpMjlkcP5W tcbKslx/K4W+ADJLH7MVEOW5zl+3eKMHnTKuK6xx8zts5D5aB1P8olsHELyptD7SwThQ kPbD3myngAyU8TlT8tLkK1uOpALKsvhj8xYEKw2jOwywunJCT6RU9cwOtdTRWl60psmC okiw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=AOTDEfp0; 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: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 14-20020a170906014e00b0087881febdd6si22760153ejh.211.2023.02.08.08.07.16; Wed, 08 Feb 2023 08:07:39 -0800 (PST) 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=AOTDEfp0; 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 S230094AbjBHQCk (ORCPT <rfc822;ivan.orlov0322@gmail.com> + 99 others); Wed, 8 Feb 2023 11:02:40 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46804 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229807AbjBHQCj (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 8 Feb 2023 11:02:39 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B50432BEF0 for <linux-kernel@vger.kernel.org>; Wed, 8 Feb 2023 08:02:37 -0800 (PST) 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 ams.source.kernel.org (Postfix) with ESMTPS id 6D1D3B81CDC for <linux-kernel@vger.kernel.org>; Wed, 8 Feb 2023 16:02:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 60543C433EF; Wed, 8 Feb 2023 16:02:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1675872155; bh=o0Ba0J+K3TeR4IycI4k6APl8pW+pR0JuMkeNS8uka64=; h=From:To:Cc:Subject:Date:From; b=AOTDEfp0F8PB7Arihfhk/am8NxmNxPm8qPiM0P2aFJK5XFxp3uBvCZRnZx57B3aKY YY6giOt1ES0SmwTKjHQsYozA3YTjVrD3y68lnEsQclSpV8T2FKYv5kzDCPP5t4B5k5 ZzYMKQyZoTXG8zYmPz6Nls73ZsNV+fxpTZYPOUlQ= From: Greg Kroah-Hartman <gregkh@linuxfoundation.org> To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Tudor Ambarus <tudor.ambarus@microchip.com>, Pratyush Yadav <pratyush@kernel.org>, Michael Walle <michael@walle.cc>, Miquel Raynal <miquel.raynal@bootlin.com>, Richard Weinberger <richard@nod.at>, Vignesh Raghavendra <vigneshr@ti.com>, linux-mtd@lists.infradead.org Subject: [PATCH v4] mtd: spi-nor: fix memory leak when using debugfs_lookup() Date: Wed, 8 Feb 2023 17:02:30 +0100 Message-Id: <20230208160230.2179905-1-gregkh@linuxfoundation.org> X-Mailer: git-send-email 2.39.1 MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=3500; i=gregkh@linuxfoundation.org; h=from:subject; bh=o0Ba0J+K3TeR4IycI4k6APl8pW+pR0JuMkeNS8uka64=; b=owGbwMvMwCRo6H6F97bub03G02pJDMmPj0+pP/3H5uiihxF/WHTUZa9Kb9vwnNfa7LfruQM56mXK mdnHO2JZGASZGGTFFFm+bOM5ur/ikKKXoe1pmDmsTCBDGLg4BWAiet8Y5vAdl+ft+HrpQf/q3VutbR ZPXH1kkTvDgp4M7RrrtUzn44Q1mSKnnXmcs/JGNAA= X-Developer-Key: i=gregkh@linuxfoundation.org; a=openpgp; fpr=F4B60CC5BF78C2214A313DCB3147D40DDB2DFB29 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1757268366366522628?= X-GMAIL-MSGID: =?utf-8?q?1757279639944319205?= |
Series |
[v4] mtd: spi-nor: fix memory leak when using debugfs_lookup()
|
|
Commit Message
Greg KH
Feb. 8, 2023, 4:02 p.m. UTC
When calling debugfs_lookup() the result must have dput() called on it,
otherwise the memory will leak over time. To solve this, remove the
lookup and create the directory on the first device found, and then
remove it when the module is unloaded.
Cc: Tudor Ambarus <tudor.ambarus@microchip.com>
Cc: Pratyush Yadav <pratyush@kernel.org>
Cc: Michael Walle <michael@walle.cc>
Cc: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Richard Weinberger <richard@nod.at>
Cc: Vignesh Raghavendra <vigneshr@ti.com>
Cc: linux-mtd@lists.infradead.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
v4: reverse the teardown order when the module is unloaded to ensure
that the debugfs directory is still around when the device directory
is removed.
v3: create the directory the first time it is used, and then remove it
if it is present when the module is unloaded. More complex than v2,
but correct.
v2: fix up to work when module is removed and added, making the fix
much simpler.
drivers/mtd/spi-nor/core.c | 14 +++++++++++++-
drivers/mtd/spi-nor/core.h | 2 ++
drivers/mtd/spi-nor/debugfs.c | 12 +++++++++---
3 files changed, 24 insertions(+), 4 deletions(-)
Comments
Am 2023-02-08 17:02, schrieb Greg Kroah-Hartman: > When calling debugfs_lookup() the result must have dput() called on it, > otherwise the memory will leak over time. To solve this, remove the > lookup and create the directory on the first device found, and then > remove it when the module is unloaded. > > Cc: Tudor Ambarus <tudor.ambarus@microchip.com> > Cc: Pratyush Yadav <pratyush@kernel.org> > Cc: Michael Walle <michael@walle.cc> > Cc: Miquel Raynal <miquel.raynal@bootlin.com> > Cc: Richard Weinberger <richard@nod.at> > Cc: Vignesh Raghavendra <vigneshr@ti.com> > Cc: linux-mtd@lists.infradead.org > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Michael Walle <michael@walle.cc> one nit below I didn't notice earlier, no need to send a new patch version just for that. .. > +void spi_nor_debugfs_shutdown(void) > +{ > + if (rootdir) > + debugfs_remove(rootdir); debugfs_remove() already has a check for NULL.
On Wed, Feb 08, 2023 at 05:15:41PM +0100, Michael Walle wrote: > Am 2023-02-08 17:02, schrieb Greg Kroah-Hartman: > > When calling debugfs_lookup() the result must have dput() called on it, > > otherwise the memory will leak over time. To solve this, remove the > > lookup and create the directory on the first device found, and then > > remove it when the module is unloaded. > > > > Cc: Tudor Ambarus <tudor.ambarus@microchip.com> > > Cc: Pratyush Yadav <pratyush@kernel.org> > > Cc: Michael Walle <michael@walle.cc> > > Cc: Miquel Raynal <miquel.raynal@bootlin.com> > > Cc: Richard Weinberger <richard@nod.at> > > Cc: Vignesh Raghavendra <vigneshr@ti.com> > > Cc: linux-mtd@lists.infradead.org > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > Reviewed-by: Michael Walle <michael@walle.cc> > > one nit below I didn't notice earlier, no need to send a new > patch version just for that. > > .. > > > +void spi_nor_debugfs_shutdown(void) > > +{ > > + if (rootdir) > > + debugfs_remove(rootdir); > > debugfs_remove() already has a check for NULL. > Argh, I knew that, for some reason I went back and added that check as I was thinking this would have been an issue if rootdir was never created. You are right, it isn't a problem, oh well. The simplest patches sometimes take the longest time to get right, I'll stop now :) thanks so much for the reviews, greg k-h
On Wed, Feb 08, 2023 at 05:15:41PM +0100, Michael Walle wrote: > Am 2023-02-08 17:02, schrieb Greg Kroah-Hartman: > > When calling debugfs_lookup() the result must have dput() called on it, > > otherwise the memory will leak over time. To solve this, remove the > > lookup and create the directory on the first device found, and then > > remove it when the module is unloaded. > > > > Cc: Tudor Ambarus <tudor.ambarus@microchip.com> > > Cc: Pratyush Yadav <pratyush@kernel.org> > > Cc: Michael Walle <michael@walle.cc> > > Cc: Miquel Raynal <miquel.raynal@bootlin.com> > > Cc: Richard Weinberger <richard@nod.at> > > Cc: Vignesh Raghavendra <vigneshr@ti.com> > > Cc: linux-mtd@lists.infradead.org > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > Reviewed-by: Michael Walle <michael@walle.cc> > > one nit below I didn't notice earlier, no need to send a new > patch version just for that. > > .. > > > +void spi_nor_debugfs_shutdown(void) > > +{ > > + if (rootdir) > > + debugfs_remove(rootdir); > > debugfs_remove() already has a check for NULL. > Ah, good catch, I merged this in when I applied it to my tree, thanks! greg k-h
Hi Greg, gregkh@linuxfoundation.org wrote on Mon, 6 Mar 2023 07:52:38 +0100: > On Wed, Feb 08, 2023 at 05:15:41PM +0100, Michael Walle wrote: > > Am 2023-02-08 17:02, schrieb Greg Kroah-Hartman: > > > When calling debugfs_lookup() the result must have dput() called on it, > > > otherwise the memory will leak over time. To solve this, remove the > > > lookup and create the directory on the first device found, and then > > > remove it when the module is unloaded. > > > > > > Cc: Tudor Ambarus <tudor.ambarus@microchip.com> > > > Cc: Pratyush Yadav <pratyush@kernel.org> > > > Cc: Michael Walle <michael@walle.cc> > > > Cc: Miquel Raynal <miquel.raynal@bootlin.com> > > > Cc: Richard Weinberger <richard@nod.at> > > > Cc: Vignesh Raghavendra <vigneshr@ti.com> > > > Cc: linux-mtd@lists.infradead.org > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > > > Reviewed-by: Michael Walle <michael@walle.cc> > > > > one nit below I didn't notice earlier, no need to send a new > > patch version just for that. > > > > .. > > > > > +void spi_nor_debugfs_shutdown(void) > > > +{ > > > + if (rootdir) > > > + debugfs_remove(rootdir); > > > > debugfs_remove() already has a check for NULL. > > > > Ah, good catch, I merged this in when I applied it to my tree, thanks! Any reasons why you did apply this patch to your tree? It is a spi-nor fix, I would have expected it to go through mtd. Thanks, Miquèl
On Mon, Mar 06, 2023 at 09:33:36AM +0100, Miquel Raynal wrote: > Hi Greg, > > gregkh@linuxfoundation.org wrote on Mon, 6 Mar 2023 07:52:38 +0100: > > > On Wed, Feb 08, 2023 at 05:15:41PM +0100, Michael Walle wrote: > > > Am 2023-02-08 17:02, schrieb Greg Kroah-Hartman: > > > > When calling debugfs_lookup() the result must have dput() called on it, > > > > otherwise the memory will leak over time. To solve this, remove the > > > > lookup and create the directory on the first device found, and then > > > > remove it when the module is unloaded. > > > > > > > > Cc: Tudor Ambarus <tudor.ambarus@microchip.com> > > > > Cc: Pratyush Yadav <pratyush@kernel.org> > > > > Cc: Michael Walle <michael@walle.cc> > > > > Cc: Miquel Raynal <miquel.raynal@bootlin.com> > > > > Cc: Richard Weinberger <richard@nod.at> > > > > Cc: Vignesh Raghavendra <vigneshr@ti.com> > > > > Cc: linux-mtd@lists.infradead.org > > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > > > > > Reviewed-by: Michael Walle <michael@walle.cc> > > > > > > one nit below I didn't notice earlier, no need to send a new > > > patch version just for that. > > > > > > .. > > > > > > > +void spi_nor_debugfs_shutdown(void) > > > > +{ > > > > + if (rootdir) > > > > + debugfs_remove(rootdir); > > > > > > debugfs_remove() already has a check for NULL. > > > > > > > Ah, good catch, I merged this in when I applied it to my tree, thanks! > > Any reasons why you did apply this patch to your tree? It is a spi-nor > fix, I would have expected it to go through mtd. It's been sitting around for a month, I assumed it was lost, so I picked it up. I can revert it if you don't want me to take it for 6.3-final through my driver core tree. thanks, greg k-h
Hi Greg, gregkh@linuxfoundation.org wrote on Mon, 6 Mar 2023 10:13:33 +0100: > On Mon, Mar 06, 2023 at 09:33:36AM +0100, Miquel Raynal wrote: > > Hi Greg, > > > > gregkh@linuxfoundation.org wrote on Mon, 6 Mar 2023 07:52:38 +0100: > > > > > On Wed, Feb 08, 2023 at 05:15:41PM +0100, Michael Walle wrote: > > > > Am 2023-02-08 17:02, schrieb Greg Kroah-Hartman: > > > > > When calling debugfs_lookup() the result must have dput() called on it, > > > > > otherwise the memory will leak over time. To solve this, remove the > > > > > lookup and create the directory on the first device found, and then > > > > > remove it when the module is unloaded. > > > > > > > > > > Cc: Tudor Ambarus <tudor.ambarus@microchip.com> > > > > > Cc: Pratyush Yadav <pratyush@kernel.org> > > > > > Cc: Michael Walle <michael@walle.cc> > > > > > Cc: Miquel Raynal <miquel.raynal@bootlin.com> > > > > > Cc: Richard Weinberger <richard@nod.at> > > > > > Cc: Vignesh Raghavendra <vigneshr@ti.com> > > > > > Cc: linux-mtd@lists.infradead.org > > > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > > > > > > > Reviewed-by: Michael Walle <michael@walle.cc> > > > > > > > > one nit below I didn't notice earlier, no need to send a new > > > > patch version just for that. > > > > > > > > .. > > > > > > > > > +void spi_nor_debugfs_shutdown(void) > > > > > +{ > > > > > + if (rootdir) > > > > > + debugfs_remove(rootdir); > > > > > > > > debugfs_remove() already has a check for NULL. > > > > > > > > > > Ah, good catch, I merged this in when I applied it to my tree, thanks! > > > > Any reasons why you did apply this patch to your tree? It is a spi-nor > > fix, I would have expected it to go through mtd. > > It's been sitting around for a month, I assumed it was lost, so I picked > it up. Sorry if it took too long, the merge window also happened during that time, we are collecting patches now that 6.3-rc1 has been released. Next time don't hesitate to ping first ;-) > I can revert it if you don't want me to take it for 6.3-final > through my driver core tree. I'll let spi-nor maintainers decide what they prefer. Thanks, Miquèl
On 06.03.2023 13:05, Miquel Raynal wrote: > Hi Greg, > > gregkh@linuxfoundation.org wrote on Mon, 6 Mar 2023 10:13:33 +0100: > >> On Mon, Mar 06, 2023 at 09:33:36AM +0100, Miquel Raynal wrote: >>> Hi Greg, >>> >>> gregkh@linuxfoundation.org wrote on Mon, 6 Mar 2023 07:52:38 +0100: >>> >>>> On Wed, Feb 08, 2023 at 05:15:41PM +0100, Michael Walle wrote: >>>>> Am 2023-02-08 17:02, schrieb Greg Kroah-Hartman: >>>>>> When calling debugfs_lookup() the result must have dput() called on it, >>>>>> otherwise the memory will leak over time. To solve this, remove the >>>>>> lookup and create the directory on the first device found, and then >>>>>> remove it when the module is unloaded. >>>>>> >>>>>> Cc: Tudor Ambarus <tudor.ambarus@microchip.com> >>>>>> Cc: Pratyush Yadav <pratyush@kernel.org> >>>>>> Cc: Michael Walle <michael@walle.cc> >>>>>> Cc: Miquel Raynal <miquel.raynal@bootlin.com> >>>>>> Cc: Richard Weinberger <richard@nod.at> >>>>>> Cc: Vignesh Raghavendra <vigneshr@ti.com> >>>>>> Cc: linux-mtd@lists.infradead.org >>>>>> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> >>>>> >>>>> Reviewed-by: Michael Walle <michael@walle.cc> >>>>> >>>>> one nit below I didn't notice earlier, no need to send a new >>>>> patch version just for that. >>>>> >>>>> .. >>>>> >>>>>> +void spi_nor_debugfs_shutdown(void) >>>>>> +{ >>>>>> + if (rootdir) >>>>>> + debugfs_remove(rootdir); >>>>> >>>>> debugfs_remove() already has a check for NULL. >>>>> >>>> >>>> Ah, good catch, I merged this in when I applied it to my tree, thanks! >>> >>> Any reasons why you did apply this patch to your tree? It is a spi-nor >>> fix, I would have expected it to go through mtd. >> >> It's been sitting around for a month, I assumed it was lost, so I picked >> it up. > > Sorry if it took too long, the merge window also happened during that > time, we are collecting patches now that 6.3-rc1 has been released. > Next time don't hesitate to ping first ;-) > >> I can revert it if you don't want me to take it for 6.3-final >> through my driver core tree. > It's fine, I don't expect other changes on these chunks of code. Anyway, if there will be merge conflicts I'll solve them locally by merging the -rc containing the fix. BTW, you forgot to cc stable and add a fixes tag :). > I'll let spi-nor maintainers decide what they prefer. > If it'll be a next time, a ping would be better. Cheers, ta
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c index d67c926bca8b..1452ed6fe5d1 100644 --- a/drivers/mtd/spi-nor/core.c +++ b/drivers/mtd/spi-nor/core.c @@ -3335,7 +3335,19 @@ static struct spi_mem_driver spi_nor_driver = { .remove = spi_nor_remove, .shutdown = spi_nor_shutdown, }; -module_spi_mem_driver(spi_nor_driver); + +static int __init spi_nor_module_init(void) +{ + return spi_mem_driver_register(&spi_nor_driver); +} +module_init(spi_nor_module_init); + +static void __exit spi_nor_module_exit(void) +{ + spi_mem_driver_unregister(&spi_nor_driver); + spi_nor_debugfs_shutdown(); +} +module_exit(spi_nor_module_exit); MODULE_LICENSE("GPL v2"); MODULE_AUTHOR("Huang Shijie <shijie8@gmail.com>"); diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h index f03b55cf7e6f..e62cd9964456 100644 --- a/drivers/mtd/spi-nor/core.h +++ b/drivers/mtd/spi-nor/core.h @@ -713,8 +713,10 @@ static inline struct spi_nor *mtd_to_spi_nor(struct mtd_info *mtd) #ifdef CONFIG_DEBUG_FS void spi_nor_debugfs_register(struct spi_nor *nor); +void spi_nor_debugfs_shutdown(void); #else static inline void spi_nor_debugfs_register(struct spi_nor *nor) {} +static inline void spi_nor_debugfs_shutdown(void) {} #endif #endif /* __LINUX_MTD_SPI_NOR_INTERNAL_H */ diff --git a/drivers/mtd/spi-nor/debugfs.c b/drivers/mtd/spi-nor/debugfs.c index ff895f6758ea..cd9c2dc07509 100644 --- a/drivers/mtd/spi-nor/debugfs.c +++ b/drivers/mtd/spi-nor/debugfs.c @@ -226,13 +226,13 @@ static void spi_nor_debugfs_unregister(void *data) nor->debugfs_root = NULL; } +static struct dentry *rootdir; + void spi_nor_debugfs_register(struct spi_nor *nor) { - struct dentry *rootdir, *d; + struct dentry *d; int ret; - /* Create rootdir once. Will never be deleted again. */ - rootdir = debugfs_lookup(SPI_NOR_DEBUGFS_ROOT, NULL); if (!rootdir) rootdir = debugfs_create_dir(SPI_NOR_DEBUGFS_ROOT, NULL); @@ -247,3 +247,9 @@ void spi_nor_debugfs_register(struct spi_nor *nor) debugfs_create_file("capabilities", 0444, d, nor, &spi_nor_capabilities_fops); } + +void spi_nor_debugfs_shutdown(void) +{ + if (rootdir) + debugfs_remove(rootdir); +}