[Top] [All Lists]

Re: [PATCH] rewrite restore_fp_context/save_fp_context

Subject: Re: [PATCH] rewrite restore_fp_context/save_fp_context
From: Atsushi Nemoto <>
Date: Thu, 16 Nov 2006 00:17:25 +0900 (JST)
In-reply-to: <> <>
Original-recipient: rfc822;
References: <> <> <>
On Tue, 14 Nov 2006 17:46:08 +0000, Ralf Baechle <> 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

On Tue, 12 Oct 2004 19:11:54 +0900 (JST), Atsushi Nemoto <> 
> 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

<Prev in Thread] Current Thread [Next in Thread>