And this is why the kernel _has_ to save the FP state.
It's the "only happens in a blue moon" bugs that are the absolute _worst_
bugs. I want to optimize the kernel until I'm blue in the face, but the
kernel must NEVER EVER have a "non-stable" interface.
Signal handlers that don't restore state are hard as _hell_ to debug. Most
of the time it doesn't really matter (unless the lack of restore is
something really major like one of the most common integer registers), but
then depending on what libraries you use, and just _exactly_ when the
signal comes in, you get subtle data corruption that may not show up until
At which point your programmer wonders if he mistakenly wandered into
No thank you. I'll take slow signal handlers over ones that _sometimes_
> After all Linux should give you enough rope to shot yourself in the foot ;)
On purpose, yes. It's ok to take careful aim, and say "I'm now shooting
myself in the foot".
And yes, it's also ok to say "I don't know what I'm doing, so I may be
shooting myself in the foot" (this is obviously the most common
And if you come to me and complain about how drunk you were, and how you
shot yourself in the foot by mistake due to that, I'll just ignore you.
BUT - and this is a big BUT - if you are doing everything right, and you
actually know what you're doing, and you end up shooting yourself in the
foot because the kernel was taking a shortcut, then I think the kernel is
And I'd rather have a slow kernel that does things right, than a fast
kernel which screws with people.
> In theory you could do a superhack: put the FP context into an unmapped
> page on the stack and only save with lazy FPU or access to the unmapped
That would be extremely interesting especially with signal handlers that
do a longjmp() thing.
The real fix for a lot of programs on x86 would be for them to never ever
use FP in the first place, in which case the kernel would be able to just
not save and restore it at all.
However, glibc fiddles with the fpu at startup, even for non-FP programs.
Dunno what to do about that.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/