Messages in this thread |  | | | Date | Sat, 28 Oct 2000 09:37:28 -0400 | | From | Brian Gerst <> | | Subject | Re: [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 majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |