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
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 :)
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.
thanks,
greg k-h
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()..
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 :)
thanks,
greg k-h
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?
Or is the above trace something that users will see when unloading
modules?
thanks,
greg k-h
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.
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?
Kay
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,
};
/*
On Thu, Dec 20, 2007 at 02:04:56PM -0800, Greg KH wrote:
> 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?
Yep, it helps!
> --- 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,
> };
>
> /*
On Sat, Dec 22, 2007 at 03:07:21PM +0300, Alexey Dobriyan wrote:
> On Thu, Dec 20, 2007 at 02:04:56PM -0800, Greg KH wrote:
> > 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?
>
> Yep, it helps!
Great, thanks for testing, I'll send the fix to Linus in a bit.
greg k-h