Kevin D. Kissell wrote: > As I wrote last night, it looks to me as if FPU context > management in signals was broken in all versions and > proposed patches that I've seen. The way I see it is this: > > If the current thread "owns" the FPU, we need to save the > FPU state in the sigcontext and restore it on return. If > the signal handler uses floating point, it already has the > FPU, and can do what it wants with it. If it doesn't use > the FPU, then we'll save and restore FPU state for > nothing, but better safe than sorry. In either case, > the current thread retains ownership of the FPU. > There is no reason to muck with the ownership data > or the Cp0.Status.CU1 enables, apart from the > questionable bit of enabling it before the FP context > save in case it wasn't enabled. I think that should go > away, but I don't have time to test exhastively. In > any case, CU1 should have it's pre-signal state > going into the signal handler. > > If the current thread does *not* own the FPU, we don't > need to save the thread FP state. If the signal handler > does no FP, so much the better, there's nothing to > be done. If the signal handler uses FP, it will acquire > the FPU by normal means. The FP context will be saved > into the thread context of the previous owner, the signalling > thread will acquire the FPU, and the signal handler will do > it's FP. On return from the signal, we *must* de-allocate the > FPU and clear the CU1 bit. If that's done, and the > thread (which had not *owned* the FPU prior to the > signal) starts doing FP again, normal mechanisms > will cause it's FP context to be restored. If we don't, > it will start exectuing with a bogus FP context. > > The code I sketched last night is essentially correct, > though it used a macro that doesn't exist. I attach a > patch relative to the current OSS repository's signal.c. > The patch includes the stack frame tweak for the FPU > emulator that was part of previous patches, but which > is orthogonal to the problem under discussion. I have > built a kernel using this code and run 20 simultaneous > copies of the MontaVista "stressor" program with no > problems (though I also had the "v1.5" FPU emulator > code). I've lost track of all the patches now :-) Can I trouble you to create a complete patch of your arch/mips/math-emu, and whatever other files you've modifed, against Ralf's tree? Pete
