Messages in this thread |  | | From | Oliver Neukum <> | Subject | Re: [RFC] Raceless module interface | Date | Thu, 12 Sep 2002 11:10:47 +0200 |
| |
> 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/
|  |