Re: kobject ->k_name memory leak
- From: Greg KH <greg@xxxxxxxxx>
- Date: Fri, 14 Dec 2007 13:48:23 -0800
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Follow-Ups:
- Re: kobject ->k_name memory leak
- From: Alexey Dobriyan
- Re: kobject ->k_name memory leak
- References:
- kobject ->k_name memory leak
- From: Alexey Dobriyan
- Re: kobject ->k_name memory leak
- From: Greg KH
- Re: kobject ->k_name memory leak
- From: Alexey Dobriyan
- Re: kobject ->k_name memory leak
- From: Greg KH
- kobject ->k_name memory leak
- Prev by Date: Re: [RFC PATCH 06/12] PAT 64b: Add ioremap_wc support
- Next by Date: Re: Top kernel oopses/warnings this week
- Previous by thread: Re: kobject ->k_name memory leak
- Next by thread: Re: kobject ->k_name memory leak
- Index(es):
Relevant Pages
|
|
