lkml.org 
[lkml]   [2002]   [Jul]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [OKS] Module removal
Werner Almesberger wrote:
> Okay, here's an almost correct example (except for the usual
> return-after-removal, plus an unlikely data race described
> below). foo_1 runs first:

This can be fixed if we assume a way to ask "is any CPU still executing
module code?".

To do this, have the `free_module' function use `smp_call_function' to
ask every CPU "are you executing code for module XXX?". The question is
answered by a routine which walks the stack, checking the instruction
pointer at each place on the stack to see whether it's inside the module
of interest.

Yes this is complex, but it's not that complex -- provided you can rely
on stack walking to find the module. (It wouldn't work if x86 used
-fomit-frame-pointer, for example).

So module removal works like this:

int free_module(...)
{
/* ...stuff... */
if (module->uc.usecount != 0)
return -EAGAIN;
if (smp_call_function (check_if_in_module, module, 1, 1))
return -EGAIN;

/* remove module. */
}

Admittedly, this _only_ deals with this particular class of race
conditions.

Another possibility would be the RCU thing: execute the module's exit
function, but keep the module's memory allocated until some safe
scheduling point later, when you are sure that no CPU can possibly be
running the module.

These don't help at all with races against parallel opens -- food for
thought, though.

-- Jamie
-
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:27    [W:0.100 / U:0.432 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site