[PATCH] invalid instructions in kernel mode

[Kumar Gala]

[snip]
>  > >The problem here is, HEY! (classic) FP instrs in the kernel.? The
>  > > question is why?? Or rather, why are these four classic FP instrs
>  > > (lfs/lfd/stfd/stfs) being done on CONFIG_4xx || E500 when neither 
> has
>  > > classic FP?? I think the problem here is that on !FPU
>  > >(which is 4xx||E500||8xx, or so), we need to rewrite these two
>  > > functions (yes, 8xx does emulate them if hit, but that's a 
> tangent).
>  >
> > What is not clear to me is what condition causes these to get hit on 
> an
> > e500.
>
> They are called in align.c from fix_alignment().  As has been said, 
> some
>  of the stress testing apps in LTP will trigger this.  Since the 
> comment
>  around the code in question (in fix_alignent()) is
>  /* Single-precision FP load and store require conversions... */
>  perhaps it's more valid to not define these functions on e500 || 4xx,
>  and make the two cases in the switch there depend on !e500 && !4xx.

What I'm concerned about what instruction is actually causing this 
fault that e500 actually gets into this case to began with.  Maybe I 
missed something in the email thread, but it would seem the only way to 
get here is via kernel emulation of the floating point load/store 
instructions, but that seems odd since they would have to be doing 
normal integer load/store... something is not quiet right in all this.

Before we go start making changes I really do want to know what 
instruction, with what effective address is causing this case to get 
triggered.

Can someone add something like the following:

if (__get_user(instr, (unsigned int __user *) regs->nip))
    return 0;

int insn_orig;
....

insn_orig = instr;

....

case LD+F+S:
     printk ("align fault [LD+F+S] for insn = %x @ %x\n", insn_orig, 
regs->nip);
..
case ST+F+S:
     printk ("align fault [ST+F+S] for insn = %x @ %x\n", insn_orig, 
regs->nip);

and report back the results.

thanks

- kumar