[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.018 / U:12.800 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site