From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Paul Mackerras <paulus@samba.org>
Cc: sfr@canb.auug.org.au, linuxppc-dev@lists.ozlabs.org,
Stuart Yoder <stuart.yoder@freescale.com>,
agraf@suse.de
Subject: Re: [PATCH v4] PPC: use CURRENT_THREAD_INFO instead of open coded assembly
Date: Fri, 13 Jul 2012 13:33:40 +1000 [thread overview]
Message-ID: <1342150420.15597.12.camel@pasglop> (raw)
In-Reply-To: <20120712224556.GA9730@bloggs.ozlabs.ibm.com>
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.
prev parent reply other threads:[~2012-07-13 3:34 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-05 14:41 [PATCH v4] PPC: use CURRENT_THREAD_INFO instead of open coded assembly Stuart Yoder
2012-07-10 22:54 ` Alexander Graf
2012-07-12 22:45 ` Paul Mackerras
2012-07-13 3:33 ` Benjamin Herrenschmidt [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1342150420.15597.12.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=agraf@suse.de \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=paulus@samba.org \
--cc=sfr@canb.auug.org.au \
--cc=stuart.yoder@freescale.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).