On Tue, 14 Nov 2006 17:46:08 +0000, Ralf Baechle <ralf@xxxxxxxxxxxxxx> wrote:
> So with this patch applied the context will be copied around twice, first
> save the fp registers to memory then copied from memory to userspace and
> as the result the non-preemptible kernel will suffer from fixing the
> preemptible ...
Yes, it is true if the signaled process owned FPU at the time. I
thought in many case the signaled process does not own FPU, but I
might be too optimistic indeed.
> To me it looks like the real problem that setup_sigcontext and
> restore_sigcontext need to disable preemption. And the reason for that
> is probably that 87d54649f67d8ffe0a8d8176de8c210a6c4bb4a7 around 2.6.9
> took the wrong. The better fix would probably have been to allow
> at least some fp instructions from kernel mode. The sole reason for
> the die_if_kernel() call is to tell people attempting to put FPU code
> into the kernel that they're screwing up.
Hmm. Two yeas ago I tried this approach to fix fpu-emulator issues
and gave up :) It was a bit complex more than it looked. Here is
excerption:
On Tue, 12 Oct 2004 19:11:54 +0900 (JST), Atsushi Nemoto <anemo@xxxxxxxxxxxxx> wrote:
> jsun> In terms of being simple, allowing kernel mode FPU trap is
> jsun> definitely simpler.
>
> jsun> If you can't find any pitfalls of this approach it is actually
> jsun> robust. The new FPU code is already greatly simplified. It is
> jsun> possible kernel FPU trap is not that evil anymore (assuming
> jsun> kernel continues voluntarily not using FPU).
>
> Hmm... OK, I agree enabling FPU trap in kernel seems simple. I tried
> it today but it did not work unfortunately. Just modifying a
> following line in traps.c was not enough.
>
> die_if_kernel("do_cpu invoked from kernel context!", regs);
>
> One point I found is do_cpu() must enable CU1 bit in pt_regs also.
> Another problem is that resume(), own_fpu() and lose_fpu() manipulate
> CU1 bit in only first level kernel stack (KSTK_STATUS(current)).
> current->thread.cp0_status may be manipulated also. Modifying
> resume() looks too dangerous to me.
But it might be a good time to try again. Do you think modifying
resume() etc. is OK?
---
Atsushi Nemoto
