Roland Dreier wrote:
Not destroying its workqueue is a bug in the module just like any other resource leak. It's analogous to a module allocating some memory with kmalloc() and not calling kfree() when it's unloaded.
Except though that with kmalloc() it's indeed just a leak while in this case things might blow up violently if run_workqueue() later accesses a workqueue_struct (or work_struct) which is already gone as part of the modules' datasection, for example. That's to say, if I'm reading this right...
I have no idea about the module refcounting stuff. Is there a chance that create_workqueue() could increase a reference somewhere so that the module wouldn't be allowed to unload untill after a destroy_workqueue()?
Rene. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
