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

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 :-)

David S. Miller

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

 \ /
  Last update: 2005-03-22 13:45    [W:0.062 / U:39.400 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site