lkml.org 
[lkml]   [2002]   [Sep]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [RFC] Raceless module interface
Date

> 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/

\
 
 \ /
  Last update: 2005-03-22 13:28    [W:0.153 / U:0.556 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site