I am sure that the kernel run do_signal() from signal_return, even if
sigpending is 0. This mean that %ebx got corrupted somewhere (and this
explain very well also the need_resched flood I suspected some days ago).
A patch for 2.1.128 that fix the UP hang fine here is this:
The puzzle is much easier to solve than you think. It probably works
most of the time by luck.
Consider how copy_thread causes the first schedule of the child to
jump to ret_from_sys_call on UP and jumps to ret_from_smpfork on SMP.
ret_from_smpfork explicitly gets current into %ebx, ret_from_sys_call
does not. For the UP case, nothing is guarenteed about the contents
of %ebx (at least how I understand the calling conventions on Intel
and what happens here) when the child is first scheduled.
What is even more amusing about this bug is that probably, now that I
think about it more, the child ends up with it's parent's task pointer
(ie. his current) in %ebx in this bit of code during the first
schedule of the child :-)
Later,
David S. Miller
davem@dm.cobaltmicro.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/