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/