In message <4450.961537780@xxxxxxxxxxxx> you write:
> On Tue, 20 Jun 2000 17:01:56 +1000,
> Rusty Russell <rusty@xxxxxxxxxxxxxxxx> wrote:
> >Races which can be largely solved at the moment by having the module
> >page removal code sync all bh's and softirqs after calling cleanup().
> >Hell, we could even poll all CPUs and check they're not executing in
> >the about-to-be-freed pages. Speed is completely unimportant here.
> This race is not obvious but IMHO it exists. The original theory was
[ Entry into other points of module during module_cleanup() example
Well, that race is obvious, IMHO.
module_cleanup should unregister everything first, before doing other
cleaning up (which might sleep). I consider this fundamental, anyway;
there's no other sane mechanism (unless you really do want to turn us
into a microkernel).
> Checking in module_cleanup() to see if the use count has changed is not
> a solution. module_cleanup() may already have destroyed structures
> that the open() code expects to use, either immediately or later.
Of course... but two-stage cleanup (as suggested by Alexey long ago)
will solve this, too.
If you have non-trivial requirements, you need to do some form of
reference counting anyway; cleanup() then just assures that the
reference count will never *rise*. When it hits zero, you call
This would certainly solve *my* problems.
I can provide code if this is still not clear how this keeps the
penalty for being a module in the module, and does not pollute the
rest of the kernel.