All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: mw@semihalf.com, linux-kernel@vger.kernel.org,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	netdev@vger.kernel.org, stable <stable@kernel.org>
Subject: Re: [PATCH net] net: mvpp2: debugfs: fix memory leak when using debugfs_lookup()
Date: Tue, 13 Sep 2022 17:55:52 +0100	[thread overview]
Message-ID: <YyC2GGbzEuCuZzMk@shell.armlinux.org.uk> (raw)
In-Reply-To: <20220902134111.280657-1-gregkh@linuxfoundation.org>

On Fri, Sep 02, 2022 at 03:41:11PM +0200, Greg Kroah-Hartman wrote:
> 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.

To clarify a bit more on the original patch rather than one of the
backported stable patches of this.

This patch introduces a bug, whereby if the driver is a module, and
is inserted, binds to a device, then is removed and re-inserted,
mvpp2_root will be NULL on the first call to mvpp2_dbgfs_init(),
so we will attempt to call debugfs_create_dir(). However, the
directory was already previously created, so this will fail, and
mvpp2_root will be the EEXIST error pointer.

Since we never clean up this directory, the original code does NOT
result in a memory leak - since the increase in refcount caused by
debugfs_lookup() has absolutely no effect - because we never remove
this directory once it's been created.

If the driver /did/ remove the directory when the module is removed,
then yes, maybe there's an argument for this fix. However, as things
currently stand, this is in no way a fix, but actually introduces a
debugfs regression.

Please can the change be reverted in mainline and all stable trees.

Thanks.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

  parent reply	other threads:[~2022-09-13 17:56 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-02 13:41 [PATCH net] net: mvpp2: debugfs: fix memory leak when using debugfs_lookup() Greg Kroah-Hartman
2022-09-05 13:20 ` patchwork-bot+netdevbpf
2022-09-13 16:55 ` Russell King (Oracle) [this message]
2022-09-14 18:03   ` Greg Kroah-Hartman
2022-09-14 18:06     ` Russell King (Oracle)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YyC2GGbzEuCuZzMk@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mw@semihalf.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=stable@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.