From: Laurent Vivier <laurent@vivier.eu>
To: Richard Henderson <richard.henderson@linaro.org>,
Shivaprasad G Bhat <sbhat@linux.vnet.ibm.com>,
dgibson@redhat.com, riku.voipio@iki.fi
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] linux-user: ppc64: don't use volatile register during safe_syscall
Date: Fri, 27 Jul 2018 10:01:06 +0200 [thread overview]
Message-ID: <8ffbfbb7-cb4b-665f-ace7-d890c75d14a8@vivier.eu> (raw)
In-Reply-To: <f8f59cca-86e6-2a42-3184-faddd51e5424@linaro.org>
Le 27/07/2018 à 06:47, Richard Henderson a écrit :
> On 07/26/2018 10:39 AM, Laurent Vivier wrote:
>> Le 26/07/2018 à 19:15, Richard Henderson a écrit :
>>> On 07/25/2018 11:48 PM, Shivaprasad G Bhat wrote:
>>>> r11 is a volatile register on PPC as per calling conventions.
>>>> The safe_syscall code uses it to check if the signal_pending
>>>> is set during the safe_syscall. When a syscall is interrupted
>>>> on return from signal handling, the r11 might be corrupted
>>>> before we retry the syscall leading to a crash. The registers
>>>> r0-r13 are not to be used here as they have
>>>> volatile/designated/reserved usages. Change the code to use
>>>> r14 which is non-volatile and is appropriate for local use in
>>>> safe_syscall.
>>>>
>>>> Signed-off-by: Shivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
>>>> ---
>>>> Steps to reproduce:
>>>> On PPC host, issue `qemu-ppc64le /usr/bin/cc -E -`
>>>> Attempt Ctrl-C, the issue is reproduced.
>>>>
>>>> Reference:
>>>> https://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.9.html#REG
>>>>
>>>> linux-user/host/ppc64/safe-syscall.inc.S | 4 ++--
>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/linux-user/host/ppc64/safe-syscall.inc.S b/linux-user/host/ppc64/safe-syscall.inc.S
>>>> index d30050a67c..b0cbbe6a69 100644
>>>> --- a/linux-user/host/ppc64/safe-syscall.inc.S
>>>> +++ b/linux-user/host/ppc64/safe-syscall.inc.S
>>>> @@ -49,7 +49,7 @@ safe_syscall_base:
>>>> * and returns the result in r3
>>>> * Shuffle everything around appropriately.
>>>> */
>>>> - mr 11, 3 /* signal_pending */
>>>> + mr 14, 3 /* signal_pending */
>>>
>>> I do see that I was incorrect in assuming that r11 would be unmodified. But
>>> you can't simply write to a call-saved register -- you must preserve its value
>>> for the caller.
>>>
>>> Saving the value requires that you find some space on, or create, a stack
>>> frame. Note that there are two different conventions for _CALL_AIX and
>>> _CALL_ELF==2.
>>
>> Can we guess the syscall ('sc') will not modify neither r11 nor r14...
>
> But sc does modify r11.
>
> li r11,0
> std r11,GPR9(r1)
> std r11,GPR10(r1)
> std r11,GPR11(r1)
>
> (Incidentally, unless I'm misreading, the kernel could have saved r11 with
> exactly as much effort as it took to clobber it to zero. That's just rude.)
>
>> but the function caller expects that r11 is not modified because it's the
>> environment pointer
>
> Huh? What do you think an "environment pointer" is in this context?
It's the comment for r11 in the section "2.2.1.1 Register Roles" of the
document.
> In the ppc64 abi, r11 is one of the ones that are clobbered by plt entries; it
> is not special in any way except as a scratch.
>
>> and saves r14 because it's one of its local
>> variable it knows it has to preserve?
>
> Huh? The caller of safe_syscall does not save r14, and does not expect it
> clobbered.
Yes, you're right. The callee has to save nonvolatile registers, and r14
is a nonvolatile register. And r11 is volatile, it's why it can be
modified by sc.
I should read the doc more carefully.
Thanks,
Laurent
next prev parent reply other threads:[~2018-07-27 8:02 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-26 6:48 [Qemu-devel] [PATCH] linux-user: ppc64: don't use volatile register during safe_syscall Shivaprasad G Bhat
2018-07-26 7:48 ` Laurent Vivier
2018-07-26 17:15 ` Richard Henderson
2018-07-26 17:39 ` Laurent Vivier
2018-07-27 4:47 ` Richard Henderson
2018-07-27 8:01 ` Laurent Vivier [this message]
2018-07-26 17:26 ` Richard Henderson
2018-07-27 6:42 ` Shivaprasad G Bhat
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=8ffbfbb7-cb4b-665f-ace7-d890c75d14a8@vivier.eu \
--to=laurent@vivier.eu \
--cc=dgibson@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=riku.voipio@iki.fi \
--cc=sbhat@linux.vnet.ibm.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).