On Wed, 28 Nov 2007, Cornelia Huck wrote:Slightly ambiguous. Instead just say: If you have initialized your kobject via kobject_init() or kobject_register(), you must not deallocate the kobject anywhere other than its release() method (which is invoked during the final kobject_put() call). Otherwise the kernel will leak memory. In theory modules shouldn't present a problem -- especially if Greg merges the "Kobjects: drop child->parent ref at unregistration" patch. When a module is unloaded, it has to unregister all its kobjects, which should force all their children to be unregistered too. At that time the children's drivers should drop all their references to the parent kobject, leaving only references held by the module being unloaded. Presumably it can arrange to drop its own references before its exit() routine returns. The only problem arises when a child's driver retains a reference to the parent kobject. If things are done properly, this reference should involve incrementing the module count -- which would prevent the module from being unloaded in the first place. Alan Stern -
| Davide Libenzi | [patch 7/8] fdmap v2 - implement sys_socket2 |
| Greg Kroah-Hartman | [PATCH 018/196] coda: convert struct class_device to struct device |
| Bart Van Assche | Integration of SCST in the mainstream Linux kernel |
| David Newall | Re: Slow DOWN, please!!! |
git: | |
| Christoph Lameter | Network latency regressions from 2.6.22 to 2.6.29 |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Arjan van de Ven | Re: [GIT]: Networking |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
