From: Helge Deller <deller@gmx.de>
To: John David Anglin <dave.anglin@bell.net>
Cc: linux-parisc@vger.kernel.org,
James Bottomley <James.Bottomley@HansenPartnership.com>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Subject: Re: [PATCH] parisc: Fix syscall restarts
Date: Sun, 20 Dec 2015 21:18:09 +0100 [thread overview]
Message-ID: <56770D01.9010608@gmx.de> (raw)
In-Reply-To: <A804D424-7C3E-4639-9EC4-5A52653EE0DD@bell.net>
On 20.12.2015 21:01, John David Anglin wrote:
> On 2015-12-20, at 2:48 PM, Helge Deller wrote:
>
>> On 20.12.2015 20:39, John David Anglin wrote:
>>> On 2015-12-18, at 6:30 PM, Helge Deller wrote:
>>>
>>>> + /* Usually we don't have to restore %r20 (the system call number)
>>>> + * because it gets loaded in the delay slot of the branch external
>>>> + * instruction via the ldi instruction.
>>>> + * In some cases a register-to-register copy instruction might have
>>>> + * been used instead, in which case we need to copy the syscall
>>>> + * number into the source register before returning to userspace.
>>>> + */
>>>
>>> I'm thinking it might be better to fix syscall() in glibc. The copy could be
>>> moved before ble and a nop placed delay slot.
>>
>> Yes, I think it should be fixed in glibc which makes it cleaner.
>> I looked at dietlibc. There a "nop" is being used.
>
> A "nop" implies %r20 needs to be restored.
Yes, I tested that. It is being restored correctly, although the comments
imply different behaviour.
>> Nevertheless, it may happen anytime if people forget, that we will see a
>> "copy" there again, so IMHO it's probably safer to include the workaround in
>> kernel too.
>
>
> The current patch assumes regs->gr[source_reg] is restored.
Yes and no.
The real problem we actually faced is, that the glibc() syscall function
uses %r28 (aka the return value of the syscall) as "source_reg".
That's the reason why we failed with "ENOSYS" in the end, because when we returned
(before my patch) from the first syscall we returned -ERESTARTSYS
in %r28 (which is basically correct), but then the "copy %r28,%r20" in
userspace moved "-ERESTARTSYS" back into %r20, jumped into the kernel, and the
kernel (correctly) reported back "ENOSYS" since there is no such syscall
number with the value of "-ERESTARTSYS".
The problem: %r28 is of course not one of the registers which is being restored.
Quite complicated... I hope I could explain it somewhat...?
> That needs to be
> checked given previous comment about %r20.
>
> Essentially, all syscall clobbered registers need to be restored.
Yes, they are (with the exception of the return value %r28).
> Can the user space stuff be avoided by jumping to the gateway entry point?
Probably.
I didn't looked into that.
Helge
next prev parent reply other threads:[~2015-12-20 20:18 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-18 23:30 [PATCH] parisc: Fix syscall restarts Helge Deller
2015-12-20 13:59 ` Mathieu Desnoyers
2015-12-20 14:09 ` Mathieu Desnoyers
2015-12-20 15:49 ` Helge Deller
2015-12-20 16:50 ` James Bottomley
2015-12-20 20:35 ` Helge Deller
2015-12-21 8:03 ` James Bottomley
2015-12-21 14:39 ` Mathieu Desnoyers
2015-12-20 18:31 ` John David Anglin
2015-12-20 19:32 ` Helge Deller
2015-12-20 19:46 ` John David Anglin
2015-12-20 20:06 ` Helge Deller
2015-12-20 23:57 ` John David Anglin
2015-12-21 14:42 ` Mathieu Desnoyers
2015-12-21 15:12 ` John David Anglin
2015-12-20 19:39 ` John David Anglin
2015-12-20 19:48 ` Helge Deller
2015-12-20 20:01 ` John David Anglin
2015-12-20 20:18 ` Helge Deller [this message]
2015-12-20 20:45 ` John David Anglin
2015-12-20 20:14 ` John David Anglin
2015-12-20 20:19 ` Helge Deller
2015-12-20 20:21 ` Helge Deller
2015-12-20 20:53 ` John David Anglin
2015-12-21 9:19 ` [PATCH] parisc: Fix syscall restarts (v2) Helge Deller
2015-12-21 13:11 ` John David Anglin
2015-12-21 20:27 ` Mathieu Desnoyers
2015-12-21 20:54 ` Helge Deller
2015-12-24 16:07 ` Mathieu Desnoyers
2015-12-24 16:51 ` John David Anglin
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=56770D01.9010608@gmx.de \
--to=deller@gmx.de \
--cc=James.Bottomley@HansenPartnership.com \
--cc=dave.anglin@bell.net \
--cc=linux-parisc@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.