Messages in this thread | | | Date | Fri, 4 Jul 2003 13:06:50 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: [PATCH 2.5.73] Signal stack fixes #1 introduce PF_SS_ACTIVE |
| |
On Fri, 4 Jul 2003, Jörn Engel wrote: > > So some application has it's signal handler on the signal stack and > instead of returning to the kernel, it detect where it left off before > the signal, mangles the last two stack frames, and goes back directly?
Yeah, basically a lot of old threading stuff did the equivalent of longjump by hand.
It is entirely possible that they do not do this out of signal handlers, since that has its own set of problems anyway, and one of the reasons for doing co-operative user level threading is to not need locking, and thus you never want to do any thread switching asynchronously (eg from a signal context).
So I'm not saying that your patch will necessarily break stuff, I'm just pointing out that it was actually done the way it is done on purpose.
> If this is correct, it definitely saves a lot of time, but it also > means that the kernel has no way to ever detect a broken signal > handler, if it operates from the signal stack.
Sure it does. It can detect just about _any_ brokenness, except for the very rare case of total stack pointer corruption.
> What is the point of the seperate signal stack anyway. I like it, > because it allows me to handle signals, even when the normal stack is > broken for some reason.
The people who use it tend to do user-space memory management, and for example put hard limits on their stack usage - possibly because they have a lot of stacks because they use threads.
Most of the time if the original stack is blown, the fault is non-recoverable. But you can use the alternate stack to either just give a nice debug message (even in the presense of otherwise non-recoverable errors), _or_ you can actually do things like fix up the stack dynamically.
Quite frankly, for the recursive SIGSEGV problem, I'd much rather look at the signal mask. If SIGSEGV is blocked, we should probably just kill the program instead of clearing the blocking and trying to handle the SIGSEGV anyway. That should fix your test case, _without_ any subtle side effects.
Linus
- 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/
| |