Message-ID: <42174DD4.9010506@keyaccess.nl>
Date: Sat, 19 Feb 2005 15:31:48 +0100
From: Rene Herman <rene.herman@keyaccess.nl>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a6) Gecko/20050111
MIME-Version: 1.0
To: Roland Dreier <roland@topspin.com>
CC: Vicente Feito <vicente.feito@gmail.com>,
       Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: workqueue - process context
References: <200502190148.11334.vicente.feito@gmail.com> <52is4ptae0.fsf@topspin.com>
In-Reply-To: <52is4ptae0.fsf@topspin.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 993
Lines: 22

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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/