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 12:21:23 -0700, Linus Torvalds wrote:
> On Fri, 4 Jul 2003, Jörn Engel wrote:
> > 
> > This is the generic part of the signal stack fixes, it simply
> > introduces a new PF-flag that indicates whether we are using the
> > signal stack right now or not.
> 
> My reason for disliking this patch is that it adds user-space information 
> to the kernel - in a place where user space cannot get at it.

Which is the whole point of it.

> In particular, any traditional cooperative user-space threading package
> wants to switch its own stack around, and they all do it by just changing
> %esp directly. The whole point of such threading is that it's _fast_,
> since it doesn't need any kernel support (and since it's cooperative, you
> can avoid locking).
> 
> The old "optimization" that you didn't like was not an optimization at 
> all: it got the case of user space changing stacks _right_, while still 
> allowing yet another stack for signal handling and exiting the signal by 
> hand.

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?

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.

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.  So the point is robustness, not performance.
If that is the only point, I don't mind making the signal stack a bit
slower, but even more robust.

Jörn

-- 
I can say that I spend most of my time fixing bugs even if I have lots
of new features to implement in mind, but I give bugs more priority.
-- Andrea Arcangeli, 2000