Re: Q: SEGSEGV && uc_mcontext->ip (Was: Signal delivery order)

["Gábor Melis" <mega@retes.hu>]

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 
handler.

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