Messages in this thread | | | Date | Mon, 16 Mar 2009 22:13:16 +0100 | From | Oleg Nesterov <> | Subject | Re: Signal delivery order |
| |
On 03/16, Gábor Melis wrote: > > In a nutshell, the context argument is wrong.
I strongly disagree. This all is correct and works as expected. Yes, it doesn't match your expectations/needs, but this doesn't mean it is wrong.
> On Lunes 16 Marzo 2009, Oleg Nesterov wrote: > > On 03/15, Gábor Melis wrote: > > > > > The revised signal-delivery-order.c (also attached) outputs: > > > > > > test_handler=8048727 > > > sigsegv_handler=804872c > > > eip: 8048727 > > > esp: b7d94cb8 > > > > > > which shows that sigsegv_handler also has incorrect eip in the > > > context. > > > > Why do you think it is not correct? > > > > I didn't try your test-case, but I can't see where "esp: b7d94cb8" > > comes from. But "eip: 8048727" looks exactly right, this is the > > address of test_handler. > > Sorry, I removed the printing of esp from the code as it was not > relevant to my point but pasted the output of a previous run. > > Anyway, I think eip is incorrect in sigsegv because it's not pointing to > the instruction that caused the sigsegv. In general the ucontext is > wrong, because it's as if sigsegv_handler were invoked within > test_handler. > > This is problematic if the sigsegv handler wants to do something with > the context. The real life sigsegv handler that's been failing does > this: > - skip the offending instruction by incrementing eip
I don't know how to solve your problem cleanly. Please let me now if you find the solution ;)
As a workaround, perhaps sigsegv_handler() can just return if uc_mcontext->ip points to another signal handler (assuming that the first instruction of the signal handler can't cause the fault). In this case the task will repeat the faulting instruction, and sigsegv_handler() will be called again.
Agreed, this is not nice and the task should track sigaction() calls, or sigsegv_handler() can do sigaction(signr, NULL, &oldact) in a loop to see which handler we have.
Can the kernel help?
Perhaps we can add si_ip to _sigfault, in this case we could just check uc_mcontext->ip != info->si_ip and return. Or we can unwind the stack and find the "correct" rt_sigframe which matches the page fault.
Or, we can change force_sig_info_fault() to block all signals except si_signo and use set_restore_sigmask() logic. This means no other signal can be dequeued until sigsegv_handler() returns.
I dunno. I am not sure your problem is common enough to do these changes, but I can't judge.
Oleg.
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |