[lkml]   [2010]   [Sep]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [GIT] Sparc
    On Wed, Sep 22, 2010 at 07:53:28PM +0100, Al Viro wrote:

    > Um, no. You've *already* called get_signal_to_deliver(). There had been
    > no SIGSEGV in sight. You happily went on to set a sigframe for e.g.
    > SIGHUP, but ran out of stack. At that point you get force_sigsegv()
    > from handle_signal(). _NOW_ you have a pending SIGSEGV; whether you'll
    > be able to handle it (e.g. if your SIGSEGV handler is set to run on
    > altstack) or not, you won't get to it until you call get_signal_to_deliver()
    > again. Which requires do_signal() to run.
    > Sure, it will be the first one to be picked, but we need to try and pick
    > _something_ to get it.

    PS: on something like x86 that'll happen before we return to userland,
    since the glue on syscall exit does that:

    testl $_TIF_DO_NOTIFY_MASK,%edx
    jz 1f
    movq %rsp,%rdi # &ptregs -> arg1
    xorl %esi,%esi # oldset -> arg2
    call do_notify_resume
    1: movl $_TIF_WORK_MASK,%edi
    jmp int_with_check

    and int_with_check leads back to int_signal if _TIF_SIGPENDING is still set.

    That kind of looping happens on everything except sparc and that's exactly
    the difference I'm talking about. On sparc the sucker manages to escape
    to userland with SIGSEGV still pending. Try it and you'll see - simple
    signal(SIGHUP, something) + munmap a little bit under your %sp +
    raise(SIGHUP), then look at the resulting coredump... On sparc you'll
    get that SIGSEGV later; in fact, putting write(1, "ouch\n", 5); after
    that raise() has a good chance of saying ouch before it dumps core.

     \ /
      Last update: 2010-09-22 21:07    [W:0.028 / U:74.060 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site