public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@suse.de>
To: Kay Sievers <kay.sievers@vrfy.org>
Cc: Alexey Dobriyan <adobriyan@gmail.com>, Greg KH <greg@kroah.com>,
	Alexey Dobriyan <adobriyan@sw.ru>,
	akpm@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: kobject ->k_name memory leak
Date: Thu, 20 Dec 2007 14:04:56 -0800	[thread overview]
Message-ID: <20071220220456.GA16307@suse.de> (raw)
In-Reply-To: <1197731956.19869.22.camel@lov.site>

On Sat, Dec 15, 2007 at 04:19:16PM +0100, Kay Sievers wrote:
> On Sat, 2007-12-15 at 16:34 +0300, Alexey Dobriyan wrote:
> > On Fri, Dec 14, 2007 at 01:48:23PM -0800, Greg KH wrote:
> > > On Mon, Dec 03, 2007 at 01:25:51PM -0800, Greg KH wrote:
> > > > On Tue, Dec 04, 2007 at 12:09:59AM +0300, Alexey Dobriyan wrote:
> > > > > On Mon, Dec 03, 2007 at 12:47:16PM -0800, Greg KH wrote:
> > > > > > On Mon, Dec 03, 2007 at 12:26:07PM +0300, Alexey Dobriyan wrote:
> > > > > > > Hi, Greg!
> > > > > > > 
> > > > > > > Commit ce2c9cb0259acd2aed184499ebe41ab00da13b25 aka
> > > > > > > "kobject: remove the static array for the name" introduced memory leak
> > > > > > > of a module name after modprobe/rmmod. Apparently for modules ->release
> > > > > > > callback is NULL.
> > > > > > > 
> > > > > > > kobject_cleanup: ->release = 00000000, name = 'foo_sysctl'
> > > > > > > Pid: 1927, comm: rmmod Not tainted 2.6.24-rc3-e1cca7e8d484390169777b423a7fe46c7021fec1 #5
> > > > > > >  [<c10d4a58>] kobject_cleanup+0xb8/0xc0
> > > > > > >  [<c10d4a60>] kobject_release+0x0/0x10
> > > > > > >  [<c10d587b>] kref_put+0x2b/0xa0
> > > > > > >  [<c11dbe85>] _spin_unlock+0x25/0x40
> > > > > > >  [<c1045b78>] free_module+0x78/0xd0
> > > > > > >  [<c104773f>] sys_delete_module+0x12f/0x1a0
> > > > > > 
> > > > > > Hm, _which_ kobject associated with a module, there are 3 of them I
> > > > > > think :)
> > > > > 
> > > > > Ouch!
> > > > > 
> > > > > > They should all have a release function, and if they do not, we think
> > > > > > it's a "static" kobject and it is not safe to free that name.
> > > > > > 
> > > > > > I've been working on cleaning this up a lot in the -mm tree with over 80
> > > > > > patches for the kset/kobject apis and interfaces.
> > > > > > 
> > > > > > But if we have a dynamic kobject, and we aren't freeing it properly,
> > > > > > please let me know which one it is and I'll work to fix it for 2.6.24.
> > > > > 
> > > > > The one which is passed to kobject_set_name() in mod_sysfs_init()..
> > > > 
> > > > That one should be set to the module_ktype, which is in kernel/params.c,
> > > > so the release function there should... oh crap, there is no release
> > > > function.  That's a bug.  After I get out of meetings tonight I'll write
> > > > up a patch for that, unless someone beats me to it :)
> > > 
> > > Ok, this is a mess.  We can't really have a release function for this
> > > kobject, as the structure it is embedded it has it's own memory
> > > management issues.
> > > 
> > > To fix this properly is going to take some major kobject/module surgery,
> > > it's not a simple fix at all.  I'll tackle it for 2.6.25, as it fits in
> > > nicely with the other kobject rework that I've already done in the -mm
> > > tree.
> > > 
> > > So, for now, can we just live with this tiny memory leak on module
> > > unload?
> > 
> > For the record, this leak screws any testing one can do wrt module
> > unload races. You can't really leave box overnight running
> > modprobe/rmmod in a loop, because OOM killer will finally kick in.
> > Hey, this is exactly how it was noticed at all.
> > 
> > > Or is the above trace something that users will see when unloading
> > > modules?
> > 
> > No, it's added debugging.
> 
> Can't we add an empty release function? It would free the name with the
> current logic, right?

Doh, that should be easy.

Alexey, can you see if the patch below fixes this issue for you?

thanks,

greg k-h

-------------------

---
 kernel/params.c |   10 ++++++++++
 1 file changed, 10 insertions(+)

--- a/kernel/params.c
+++ b/kernel/params.c
@@ -697,8 +697,18 @@ static struct kset_uevent_ops module_uev
 decl_subsys(module, &module_ktype, &module_uevent_ops);
 int module_sysfs_initialized;
 
+static void module_release(struct kobject *kobj)
+{
+	/*
+	 * Stupid empty release function to allow the memory for the kobject to
+	 * be properly cleaned up.  This will not need to be present for 2.6.25
+	 * with the upcoming kobject core rework.
+	 */
+}
+
 static struct kobj_type module_ktype = {
 	.sysfs_ops =	&module_sysfs_ops,
+	.release = module_release,
 };
 
 /*

  reply	other threads:[~2007-12-20 22:06 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-03  9:26 kobject ->k_name memory leak Alexey Dobriyan
2007-12-03 20:47 ` Greg KH
2007-12-03 21:09   ` Alexey Dobriyan
2007-12-03 21:25     ` Greg KH
2007-12-14 21:48       ` Greg KH
2007-12-15 13:34         ` Alexey Dobriyan
2007-12-15 15:19           ` Kay Sievers
2007-12-20 22:04             ` Greg KH [this message]
2007-12-22 12:07               ` Alexey Dobriyan
2007-12-23  5:55                 ` Greg KH

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=20071220220456.GA16307@suse.de \
    --to=gregkh@suse.de \
    --cc=adobriyan@gmail.com \
    --cc=adobriyan@sw.ru \
    --cc=akpm@osdl.org \
    --cc=greg@kroah.com \
    --cc=kay.sievers@vrfy.org \
    --cc=linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox