> To make this work, we rely on the rule that no module code may
> sleep/schedule unless it first increments a counter. The counter
> incremented will, at present, be the module->count, but that is entirely
> up to the module itself; module.c will no longer care how it keeps
> track, as long as it does.
>
> With config_preempt code, we must additionally disable preemption until
> the module quiescence test has completed. I'm not going to go further
> into this, because this is deep scheduling-fu, and I haven't got working
> code to show yet. Suffice to say that we have the technology to build a
> magic_wait_for_quiescence, and we must now proceed to do that. (Robert,
> are you reading?) A noncounting module uses the test as follows, in its
> cleanup_function:
>
> unregister_callpoints(...);
> magic_wait_for_quiescence();
> return cleanup_foo(...);
Please correct me if I am wrong, but ...
Task A Task B counter
call_module() +1
schedule() still 1
unregister_callpoints() still 1
magic_wait_for_quiescence(); still 1
call_module_second_func() -> Won't work
So by trying to unregister a module you make a module unusable
for an unspecified amount of time.
Regards
Oliver
-
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 : Sun Sep 15 2002 - 22:00:28 EST