[PATCH] invalid instructions in kernel mode

[Fillod Stephane]

Hi Dan,

Please be aware I am no expert in that field, so bear with me :)

Dan Malek wrote:
>> When CPU has no (classic) FPU, and math emulation is disabled,
>> fp instructions are not allowed in kernel mode.
>
>FP Instructions are never allowed in kernel mode regardless of the CPU.
>However, with math emulation disabled and no FPU, we still emulate
>FP load/store operations because they are usually hard coded in
>some of the context save/restore functions of the C library.

What I don't understand, is how the FP load/store operations
in misc.S can "work" on a system with no FPU and *no* math-emu?

>> This bug has been found with crashme (crash01) of LTP, on a e500 
>> system.
>
>What is the bug?  This patch disables a big feature we have been
>using for many years.  Please take another look at this.

Many years? Allow me to doubt it's really used :). I took a better 
look, at math-emu/math.c. And then I understood why my previous
patch should not have disabled cvt_fd et al in misc.S.

The fact is, with CONFIG_MATH_EMULATION disabled, make does not enter
the math-emu/ subdir, math.c does not get compiled (so no lfs/etc.
emulation), and  by the way, nobody even call do_mathemu in
traps.c because it's always surrounded with #ifdef
CONFIG_MATH_EMULATION.
Though, it does work for 8xx thanks to Soft_emulate_8xx, but doesn't
for other FPU-less cores when CONFIG_MATH_EMULATION is disabled.

So here is another patch, which hopefully is a better fix,
yet find a solution to my problem. Please comment on it,
as I'm not sure whether ProgramCheckException is right.
Rem: it looks weird to use FP load/store operations when
you do know that you don't have a FPU and CONFIG_MATH_EMULATION
is disabled. Should we do like 8xx, and call directly
the emulation layer? Could we re-use Soft_emulate_8xx() (made generic
without the *_8xx_pte) for the 4xx and e500 ?


Signed-off-by: Stephane Fillod <fillods at gmail.com> 

--- linux/arch/ppc/Makefile	26 Mar 2005 03:28:39 -0000	1.1.1.2
+++ linux/arch/ppc/Makefile	31 Mar 2005 18:59:25 -0000
@@ -55,10 +55,10 @@
 head-$(CONFIG_POWER4)		+= arch/ppc/kernel/idle_power4.o
 
 core-y				+= arch/ppc/kernel/ arch/ppc/platforms/
\
-				   arch/ppc/mm/ arch/ppc/lib/
arch/ppc/syslib/
+				   arch/ppc/mm/ arch/ppc/lib/
arch/ppc/syslib/ \
+				   arch/ppc/math-emu/
 core-$(CONFIG_4xx)		+= arch/ppc/platforms/4xx/
 core-$(CONFIG_85xx)		+= arch/ppc/platforms/85xx/
-core-$(CONFIG_MATH_EMULATION)	+= arch/ppc/math-emu/
 core-$(CONFIG_XMON)		+= arch/ppc/xmon/
 core-$(CONFIG_APUS)		+= arch/ppc/amiga/
 drivers-$(CONFIG_8xx)		+= arch/ppc/8xx_io/
--- linux/arch/ppc/kernel/traps.c	30 Mar 2005 16:25:07 -0000
1.3
+++ linux/arch/ppc/kernel/traps.c	31 Mar 2005 18:59:25 -0000
@@ -540,7 +540,6 @@
 	    return;
 #endif /* CONFIG_ADEOS_CORE */
 
-#ifdef CONFIG_MATH_EMULATION
 	/* (reason & REASON_ILLEGAL) would be the obvious thing here,
 	 * but there seems to be a hardware bug on the 405GP (RevD)
 	 * that means ESR is sometimes set incorrectly - either to
@@ -552,7 +551,6 @@
 		emulate_single_step(regs);
 		return;
 	}
-#endif /* CONFIG_MATH_EMULATION */
 
 	if (reason & REASON_FP) {
 		/* IEEE FP exception */
--- linux/arch/ppc/kernel/process.c	26 Mar 2005 03:28:20 -0000
1.1.1.2
+++ linux/arch/ppc/kernel/process.c	31 Mar 2005 18:59:25 -0000
@@ -342,7 +342,7 @@
 	printk("\n");
 #ifdef CONFIG_KALLSYMS
 	/*
-	 * Lookup NIP late so we have the best change of getting the
+	 * Lookup NIP late so we have the best chance of getting the
 	 * above info out without failing
 	 */
 	printk("NIP [%08lx] ", regs->nip);



Thanks for the reply
-- 
Stephane