On Fri, 2012-07-13 at 08:45 +1000, Paul Mackerras wrote: > On Thu, Jul 05, 2012 at 09:41:35AM -0500, Stuart Yoder wrote: > > > diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S > > index ba3aeb4..bad42e3 100644 > > --- a/arch/powerpc/kernel/entry_32.S > > +++ b/arch/powerpc/kernel/entry_32.S > > @@ -92,7 +92,7 @@ crit_transfer_to_handler: > > mfspr r8,SPRN_SPRG_THREAD > > lwz r0,KSP_LIMIT(r8) > > stw r0,SAVED_KSP_LIMIT(r11) > > - rlwimi r0,r1,0,0,(31-THREAD_SHIFT) > > + CURRENT_THREAD_INFO(r0, r1) > > stw r0,KSP_LIMIT(r8) > > /* fall through */ > > #endif > > @@ -112,7 +112,7 @@ crit_transfer_to_handler: > > mfspr r8,SPRN_SPRG_THREAD > > lwz r0,KSP_LIMIT(r8) > > stw r0,saved_ksp_limit@l(0) > > - rlwimi r0,r1,0,0,(31-THREAD_SHIFT) > > + CURRENT_THREAD_INFO(r0, r1) > > stw r0,KSP_LIMIT(r8) > > /* fall through */ > > #endif > > Do you really mean to replace a rlwimi with a rlwinm? If so, is that > because the rlwinm is a bug fix, or is it because you know something > special about KSP_LIMIT(r8) which means that rlwinm and rlwimi are > equivalent here?
Ah that's an interesting one I hadn't spotted when reviewing. Both variants (rlwimi and rlwinm) will effectively replace the top bits of KSP_LIMIT, switching it to the current stack. The difference is that the original one (rlwimi) will preserve the bottom bits. Now, do we want those bottom bits ? It looks like we do if we want to make the thread_info at the bottom of the stack as "out of bounds". So the patch breaks that. It will not generally break a working kernel but the stack overflow detection may not trigger if the overflow is just enough to override the thread infos. Stuart, I already applied v4 of the patch to powerpc-next and I'd rather not rebase it, can you send a fixup patch please, one that will effecticely revert those two hunks, we can leave that open coded. While at it, please add a comment explaining what the code does to avoid similar confusion in the future. Cheers, Ben. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev