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