Re: Signal delivery order

[Chris Friesen]

Oleg Nesterov wrote:
> 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.

It would appear that standard may allow this, depending on interpretation.

From SUSv3, regarding sigaction():

"...the third argument can be cast to a pointer to an object of type 
ucontext_t to refer to the receiving thread's context that was 
interrupted when the signal was delivered."

From the "signal concepts" section, "A signal is said to be 
``delivered'' to a process when the appropriate action for the process 
and signal is taken."

Given that the SIGSEGV isn't "delivered" until it's handler runs, it 
could possibly be valid for the instruction pointer in the SIGSEGV 
handler to reference test_handler, if the system was set up in such a 
way that the context was set to test_handler() at the time the SIGSEGV 
handler was run.

However, there are quality-of-implementation issues here--being able to 
handle SIGSEGV is pretty useless if the instruction pointer being passed 
to the handler doesn't actually match the instruction that caused the 
segfault.

> I dunno. I am not sure your problem is common enough to do these
> changes, but I can't judge.

What he's trying to do isn't all that unusual.  Certainly any 
application wanting to do something smart (log the instruction pointer, 
for instance) on a segfault could run into the same problem.

Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/