[lkml]   [2000]   [Oct]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PROPOSED PATCH] ATM refcount + firestream
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
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:45    [W:0.090 / U:0.496 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site