Re: Race condition in module load causing undefined symbols

From: David Howells
Date: Thu Jul 28 2005 - 14:44:53 EST

Hi Steve,

Someone's finally waved this discussion in my direction.

> Still puzzled about what could have been fixed in user space since this
> appears to affect more than one shell. Module loading appears to be
> very synchronous, so unless the shell was not waiting for exit status
> on children correctly, it seems hard to explain in user space.

The problem with nash is very simple, and may be duplicated in other shells:

(1) The patch to the module wangling patch that I made makes use of
stop_machine_run() to insert a module into the module list or remove it
from the module list.

This is done because certain things that look at the list have to run
without locks, so the only way to be certain they aren't going to run is
to ensure that _nothing_ else is going to run.

(2) stop_machine_run() creates a bunch of kernel threads to hog the other
CPUs with interrupts disabled whilst one CPU does the actual work.

(3) These kernel threads are reparented to the init process (PID 1).

(4) When "parentless" threads exit, whatever process is running as PID 1 gets
to deal with the zombies and will get a wait() event for each.

(5) nash runs as PID 1 during boot.

(6) nash was NOT checking the pid returned by its calls to wait(); in
especial, when it forked off an insmod process, it would then simply wait
for the first wait event to happen and continue on, without checking that
the process it was waiting for had actually finished.

That is the basic problem being seen. It's just that it rarely happens without
this patch, but the problem is still there in nash, and could be triggered due
to other parentless processes exiting or dying.

I got nash patched, but it seems to be taking awhile to percolate.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at