Keith Owens wrote:
> The only difference between module and non-module is whether the code
> and data areas are freed or left in the kernel for the next user.
Yes, that's exactly why the entry-after-removal problem worries me:
this is something that also means trouble if you're a non-module.
Just remember the "timer pops after del_timer" problem a while back.
De-registration that leaves stuff behind is extremely dangerous, no
matter if you're a module or not.
I fully agree that return-after-removal is a different issue and
that there are several perfectly reasonable ways for dealing with
this.
> Ensuring that all code has either dropped stale references or bumped
> the use count means that all processes that were not sleeping when
> rmmod was started must proceed to a sync point. It is (and always has
> been) illegal to sleep while using module code/data (note: using, not
> referencing).
That's the problem with entry-after-removal: you may simply not be
able to know when all references are gone.
Since basically all references to modules go through some sort of
registration function, why not fix the registration functions ?
- Werner
-- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://icapeople.epfl.ch/almesber/_____________________________________/ - 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/
This archive was generated by hypermail 2b29 : Mon Jul 15 2002 - 22:00:14 EST