From: Nicholas Piggin <npiggin@gmail.com>
To: "Christopher M. Riedl" <cmr@codefail.de>,
linuxppc-dev@lists.ozlabs.org,
Michael Ellerman <mpe@ellerman.id.au>
Subject: Re: [PATCH] powerpc64/idle: Fix SP offsets when saving GPRs
Date: Sat, 30 Jan 2021 23:44:08 +1000 [thread overview]
Message-ID: <1612014056.e1qcnzac7c.astroid@bobo.none> (raw)
In-Reply-To: <87o8h6d5jg.fsf@mpe.ellerman.id.au>
Excerpts from Michael Ellerman's message of January 30, 2021 9:32 pm:
> "Christopher M. Riedl" <cmr@codefail.de> writes:
>> The idle entry/exit code saves/restores GPRs in the stack "red zone"
>> (Protected Zone according to PowerPC64 ELF ABI v2). However, the offset
>> used for the first GPR is incorrect and overwrites the back chain - the
>> Protected Zone actually starts below the current SP. In practice this is
>> probably not an issue, but it's still incorrect so fix it.
>
> Nice catch.
>
> Corrupting the back chain means you can't backtrace from there, which
> could be confusing for debugging one day.
Yeah, we seem to have got away without noticing because the CPU will
wake up and return out of here before it tries to unwind the stack,
but if you tried to walk it by hand if the CPU got stuck in idle or
something, then we'd get confused.
> It does make me wonder why we don't just create a stack frame and use
> the normal macros? It would use a bit more stack space, but we shouldn't
> be short of stack space when going idle.
>
> Nick, was there a particular reason for using the red zone?
I don't recall a particular reason, I think a normal stack frame is
probably a good idea.
Thanks,
Nick
next prev parent reply other threads:[~2021-01-30 14:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-30 3:04 [PATCH] powerpc64/idle: Fix SP offsets when saving GPRs Christopher M. Riedl
2021-01-30 11:32 ` Michael Ellerman
2021-01-30 13:44 ` Nicholas Piggin [this message]
2021-02-04 6:59 ` Christopher M. Riedl
2021-02-04 9:05 ` Nicholas Piggin
2021-02-04 11:13 ` Michael Ellerman
2021-02-04 11:26 ` Nicholas Piggin
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=1612014056.e1qcnzac7c.astroid@bobo.none \
--to=npiggin@gmail.com \
--cc=cmr@codefail.de \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
/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).