Re: Race condition in module load causing undefined symbols

[David Howells <dhowells@redhat.com>]

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.

David