From: Keith Owens <kaos@ocs.com.au>
To: linux-kernel@vger.kernel.org
Subject: Re: [OKS] Module removal 
In-reply-to: Your message of "Tue, 02 Jul 2002 00:08:55 -0400."
             <3D212757.5040709@quark.didntduck.org> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 02 Jul 2002 14:53:15 +1000
Message-ID: <32193.1025585595@kao2.melbourne.sgi.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1729
Lines: 36

On Tue, 02 Jul 2002 00:08:55 -0400, 
Brian Gerst <bgerst@quark.didntduck.org> wrote:
>Keith Owens wrote:
>> 1) Do the reference counting outside the module, before it is entered.
>>    Not only does this pollute all structures that contain function
>>    pointers, it introduces overhead on every function dereference.  All
>>    of this just to cope with the relatively low possibility that a
>>    module will be removed.
>
>Only "first use" (ie. ->open) functions need gaurding against unloads. 
>Any subsequent functions are guaranteed to have a reference to the 
>module, and don't need to bother with the refcount.  I have a few ideas 
>to optimize the refcounting better than it is now.

Also the close routine, otherwise there is a window where the use count
is 0 but code is still executing in the module.

Network operations such as SIOCGIFHWADDR take an interface name and do
not call any 'open' routine.  The only lock I can see around dev_ifsioc
is dev_base_lock, AFAICT that will not protect against a module being
unloaded while SIOCGIFHWADDR is running.  If dev_base_lock does protect
against module unload, it is not clear that it does so.

For netfilter, the use count reflects the number of packets being
processed.  Complex and potentially high overhead.

All of this requires that the module information be passed in multiple
structures and assumes that all code is careful about reference
counting the code it is about to execute.  There has to be a better
way!

-
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/