[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.079 / U:3.412 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site