Re: [PATCH 2.5.73] Signal stack fixes #1 introduce PF_SS_ACTIVE

["Jörn Engel" <joern@wohnheim.fh-wedel.de>]

On Fri, 4 July 2003 13:06:50 -0700, Linus Torvalds wrote:
> 
> 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.

And there actually is a possibility for my patch to break things.
Davide's example should still work, but there may be others.  Point
taken.

> Sure it does. It can detect just about _any_ brokenness, except for the 
> very rare case of total stack pointer corruption.

Well, that rare case is one that some people are quite concerned
about.  The sigaltstack is nice because it reduces the likelyhood, but
it doesn't cure the paranoia completely.

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

Both of which I want to have, right.

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

What do we do, if a program also uses SA_NOMASK for the SIGSEGV
handler?  This is totally stupid, I agree, but it is legal.  Should we
declare it illegal from this day on, or is that path blocked as well?

Jörn

-- 
When in doubt, use brute force.
-- Ken Thompson