[lkml]   [2006]   [May]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 2.6.17-rc2-mm1
    >> ><EOE>new stack 0 (0 0 0 10082 10)
    >> Looks like <rubbish> <SS> <RSP> <RFLAGS> <CS> to me, ...
    >Hmm, right.
    >> >Hmm weird. There isn't anything resembling an exception frame at the top of the
    >> >stack. No idea how this could happen.
    >> ... which is a valid frame where the stack pointer was corrupted before the exception occurred. One more printed
    >> (or rather, starting items at estack_end[-1]) would allow at least seeing what RIP this came from.
    >Any can you add that please and check?


    >Also worst case one could dump last branch pointers. AMD unfortunately only has four,
    >on Intel with 16 it's easier.

    Provided you disable recording early enough. Otherwise only one (last exception from/to) is going to be useful on

    >I can provide a patch for that if needed.
    >> This actually points out another weakness of that code: if you pick up a mis-aligned stack pointer then the
    >> in both the exception and interrupt stack invocations of HANDLE_STACK() won't prevent you from accessing an item
    >> crossing a page boundary, and hence potentially faulting.
    >Yes it probably should check for that.
    >> Similarly, obtaining an entirely bad stack pointer anywhere in
    >> that code will result in a fault. I guess the stack reads should really be done using get_user() or some other code
    >> having recovery attached.
    >That can cause recursive exceptions. I'm a bit paranoid with that.

    Without doing so it can also cause recursive exceptions, just that this is going to be deadly then.

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

     \ /
      Last update: 2006-05-03 09:10    [W:0.021 / U:17.832 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site