lkml.org 
[lkml]   [1998]   [Nov]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: entry.S mess with %ebx (&current pointer)
   Date: 	Thu, 19 Nov 1998 11:45:40 +0100 (CET)
From: Andrea Arcangeli <andrea@e-mind.com>

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/

\
 
 \ /
  Last update: 2005-03-22 13:45    [from the cache]
©2003-2011 Jasper Spaans