Messages in this thread | | | Date | Fri, 5 Jul 2002 10:40:49 +0100 | From | Stephen Tweedie <> | Subject | Re: simple handling of module removals Re: [OKS] Module removal |
| |
Hi,
On Thu, Jul 04, 2002 at 01:48:59AM +0200, Daniel Phillips <phillips@arcor.de> wrote:
> Is it just the mod_dec_use_count; return/unload race we're worried about? > I'm not clear on why this is hard. I'd think it would be sufficient just to > walk all runnable processes to ensure none has an execution address inside the > module.
That fails if:
the module function has called somewhere else in the kernel (and with -fomit-frame-pointer, you can't reliably walk back up the stack to find out if there is a stack frame higher up the stack which is in the module);
the module has taken an interrupt into an unrelated driver;
we have computed a call into the module but haven't actually executed the call yet;
etc.
> For smp, an ipi would pick up the current process on each cpu.
Without freezing the other CPUs, that still leaves the race wide open.
--Stephen - 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/
| |