[lkml]   [2009]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Q: SEGSEGV && uc_mcontext->ip (Was: Signal delivery order)
    On Martes 17 Marzo 2009, Linus Torvalds wrote:
    > On Tue, 17 Mar 2009, Gábor Melis wrote:
    > > As an application developer what I'd like to have is this:
    > > synchronously generated signals are delivered before asynchronously
    > > generated ones.
    > I agree that it would be nice, but quite frankly, it's simply not how
    > signals work. It would be a reasonably invasive change, and you
    > wouldn't really be able to rely on it anyway since most kernels don't
    > work that way.

    True. I won't be able to rely on this and I'll stick to the SIGUSR2
    workaround that's confirmed by Oleg.

    > What you might be able to do instead is to walk signal frames
    > backwards by hand. IOW, accept the fact that sometimes signals end up
    > being nested, but then you could try to find the right frame by just
    > looking at them.

    Walking the frames is not enough, because even if the right one is
    found, I can't put a new frame on it if it's not at the top ...

    > And your trick of comparing 'info->si_ip' with
    > 'context->uc_mcontext->ip' is pretty good, and lets the code itself
    > walk the signal frames by just depending on the fault happening
    > again.

    Another example. Suppose there is a stack with a mprotected guard page
    at the end. The app's stack grows into the guard page, sigsegv is
    generated, its handler would be invoked, but a pthread_kill'ed SIGUSR1
    gets delivered first. Now the SIGUSR1 handler accesses the stack and
    triggers another fault, the sigsegv handler sees that si_ip ==
    uc_mcontext->ip, so it unprotects the page and puts a frame on the
    stack, arranging for a function to be called. Then the function
    deadlocks because it waits for a signal that's blocked in the SIGUSR1

    I think it would be a definite improvement to prevent all these
    headaches from occurring and deliver asynchronously generated, thread
    private signals after the synchronous ones.

    > Linus
    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: 2009-03-18 11:01    [W:0.023 / U:34.068 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site