altivec_unavailable_exception is called without setting r3... it looks like
the r3 that actually gets passed in as struct pt_regs *regs is the
undisturbed value of r3 at the time the altivec instruction was encountered.
The user actually gets to choose the pt_regs printed in the Oops!
After applying the following patch to 2.6.16-rc4, I can no longer cause an
Oops by executing an altivec instruction with CONFIG_ALTIVEC=n. The same
change would probably also be good for arch/ppc/kernel/head.S to fix the same
Oops in 2.6.15.4, though I haven't tested that.
--- arch/powerpc/kernel/head_32.S.orig 2006-02-21 15:58:18.000000000 -0500
+++ arch/powerpc/kernel/head_32.S 2006-02-21 15:59:23.000000000 -0500
@@ -714,6 +714,7 @@
#ifdef CONFIG_ALTIVEC
bne load_up_altivec /* if from user, just load it up */
#endif /* CONFIG_ALTIVEC */
+ addi r3,r1,STACK_FRAME_OVERHEAD
EXC_XFER_EE_LITE(0xf20, altivec_unavailable_exception)
PerformanceMonitor:
On Feb 21, 2006, at 5:39 PM, Alan Curry wrote:
> altivec_unavailable_exception is called without setting r3... it
> looks like
> the r3 that actually gets passed in as struct pt_regs *regs is the
> undisturbed value of r3 at the time the altivec instruction was
> encountered.
> The user actually gets to choose the pt_regs printed in the Oops!
>
> After applying the following patch to 2.6.16-rc4, I can no longer
> cause an
> Oops by executing an altivec instruction with CONFIG_ALTIVEC=n. The
> same
> change would probably also be good for arch/ppc/kernel/head.S to
> fix the same
> Oops in 2.6.15.4, though I haven't tested that.
>
> --- arch/powerpc/kernel/head_32.S.orig 2006-02-21
> 15:58:18.000000000 -0500
> +++ arch/powerpc/kernel/head_32.S 2006-02-21 15:59:23.000000000 -0500
> @@ -714,6 +714,7 @@
> #ifdef CONFIG_ALTIVEC
> bne load_up_altivec /* if from user, just load it up */
> #endif /* CONFIG_ALTIVEC */
> + addi r3,r1,STACK_FRAME_OVERHEAD
> EXC_XFER_EE_LITE(0xf20, altivec_unavailable_exception)
>
> PerformanceMonitor:
Would you mine providing a patch for arch/ppc/kernel/head.S and
adding a signed-off-by line.
- k
Kumar Gala writes the following:
>
>Would you mine providing a patch for arch/ppc/kernel/head.S and
>adding a signed-off-by line.
OK, combined patch... applies clean to 2.6.16-rc4, applies with fuzz to
2.6.15.4, both compiled and tested. Patch prevents Oopsing of
CONFIG_ALTIVEC=n kernel by user executing altivec instruction in both cases.
Signed-off-by: Alan Curry <[email protected]>
--- arch/ppc/kernel/head.S.orig 2006-02-21 20:58:08.000000000 -0500
+++ arch/ppc/kernel/head.S 2006-02-21 20:58:11.000000000 -0500
@@ -751,6 +751,7 @@ AltiVecUnavailable:
#ifdef CONFIG_ALTIVEC
bne load_up_altivec /* if from user, just load it up */
#endif /* CONFIG_ALTIVEC */
+ addi r3,r1,STACK_FRAME_OVERHEAD
EXC_XFER_EE_LITE(0xf20, altivec_unavailable_exception)
#ifdef CONFIG_PPC64BRIDGE
--- arch/powerpc/kernel/head_32.S.orig 2006-02-21 15:58:18.000000000 -0500
+++ arch/powerpc/kernel/head_32.S 2006-02-21 15:59:23.000000000 -0500
@@ -714,6 +714,7 @@ AltiVecUnavailable:
#ifdef CONFIG_ALTIVEC
bne load_up_altivec /* if from user, just load it up */
#endif /* CONFIG_ALTIVEC */
+ addi r3,r1,STACK_FRAME_OVERHEAD
EXC_XFER_EE_LITE(0xf20, altivec_unavailable_exception)
PerformanceMonitor:
Alan Curry writes:
> altivec_unavailable_exception is called without setting r3... it looks like
> the r3 that actually gets passed in as struct pt_regs *regs is the
> undisturbed value of r3 at the time the altivec instruction was encountered.
Nice catch!
Thanks,
Paul.