hang from HUP'ing init in linuxrc

hang from HUP'ing init in linuxrc

[Paul Mackerras]

Recently I tried running the Debian installer on top of a 2.4.6-pre6
kernel.  It got up to the point of installing libc and then the system
hung.  It was still taking interrupts (I could change vt's, etc.) but
no user processes were running.

What was happening was rather interesting.  The init process was stuck
inside prepare_namespace(), in the while loop here (this is lines 749
- 751 of init/main.c):

		pid = kernel_thread(do_linuxrc, "/linuxrc", SIGCHLD);
		if (pid>0)
			while (pid != wait(&i));

The installer had sent a HUP signal to init.  The init process thus
had current->sigpending == 1.  When it called wait, it got down into
sys_wait4 which worked out that there were children but none were
zombies, and at that point it would normally sleep, but because there
were signals pending, it returned -ERESTARTSYS.  Now, on the way out
from the system call, the kernel noticed that it was returning to
kernel mode and thus didn't deliver any signals, and sigpending stayed
at 1.

Thus the system was sitting in a tight loop calling wait() over and
over again in kernel mode in the init process.

This was on PPC.  I had a look at the i386 code and AFAICS it will do
the same thing.  The check for whether we are returning to user mode
is in do_signal there (whereas PPC does the check in entry.S) but the
net effect in both cases is that we don't execute the main body of
do_signal when we are returning from a syscall from a process running
in kernel mode.

I'm not sure what the best way to fix this is.  The problem would crop
up whenever we have a kernel thread which wants to wait for a child
process.  I don't think we want to start delivering signals to kernel
threads in the same way that we do to usermode processes though.

Any suggestions?

Paul.

Re: hang from HUP'ing init in linuxrc

[Ben LaHaise]

On Mon, 2 Jul 2001, Paul Mackerras wrote:

> I'm not sure what the best way to fix this is.  The problem would crop
> up whenever we have a kernel thread which wants to wait for a child
> process.  I don't think we want to start delivering signals to kernel
> threads in the same way that we do to usermode processes though.
>
> Any suggestions?

Well, linuxrc and a number of aspects of the boot process seem to suffer
from attempting to kludge userspace programs into the kernel.  To this
end, I would like to propose that we move these functions into userspace
where they belong and instead provide support for linking an initial
filesystem image into vmlinux.  We can then move linuxrc, dhcp and other
such bits out of the kernel and use the same code as is normally used at
run time -> it's better tested and easier to fix.

		-ben

Re: hang from HUP'ing init in linuxrc

[David S. Miller]

Paul Mackerras writes:
 > What was happening was rather interesting.  The init process was stuck
 > inside prepare_namespace(), in the while loop here (this is lines 749
 > - 751 of init/main.c):
 > 
 > 		pid = kernel_thread(do_linuxrc, "/linuxrc", SIGCHLD);
 > 		if (pid>0)
 > 			while (pid != wait(&i));
 > 
 ...
 [ no signal delivery due to returning to kernel space, blah blah blah
   :-) ]

For 2.4.x I'd just check for sigpending in this wait loop.

Longer term (ie. 2.5.x and onward) we should look into ideas like those
mentioned by Ben.  I for one would not complain about seeing dhcp
getting removed from the kernel :-)

Later,
David S. Miller
davem@redhat.com