Re: [PROPOSED PATCH] ATM refcount + firestream

[Brian Gerst <bgerst@didntduck.org>]

Philipp Rumpf wrote:
> 
> On Fri, Oct 27, 2000 at 10:49:53PM +1100, Andrew Morton wrote:
> > Look, this modules stuff is really bad.  Phillip Rumpf proposed
> > a radical alternative a while back which I felt was not given
> 
> While it might be a "radical alternative", it doesn't require any changes
> to the subsystems that have been fixed so far.  At this time, applying the
> patch would basically fix the rest of the subsystems as well (if the
> drivers use MOD_{INC,DEC}_USE_COUNT, that is).
> 
> > sufficient consideration.  The idea was to make sys_delete_module()
> > grab all the other CPUs and leave them spinning on a flag while
> > the unload was proceeding.  This was very similar to
> > arch/i386/kernel/apm.c:apm_power_off().
> 
> The idea here is other CPUs don't have to deal with the kernel going
> through a number of inconsistent states while a module is unloaded.  At
> any point in time, for any module, exactly one of the following is true:
> 
> 1. you're in the module_exit function
> 2. the module is (being) loaded
> 3. the module isn't loaded.
> 
> > As far as I can recall, the only restriction was that you are
> > not allowed to call module functions when the module refcount
> > is zero if those functions can call schedule().
> 
> There are other restrictions which shouldn't really matter:
> 
>  - you can't schedule() and hope you end up on a particular CPU (you can
> use smp_call_function though)
> 
>  - you can't copy_(from|to)_user in the module exit function (which would
> be copies from/to rmmod anyway)

Unfortunately, you need to be able to use copy_*_user() from the network
ioctls, and this is the center of the current issue.

-- 

						Brian Gerst
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/