[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7919ae8b-958b-4b12-a5f4-8be2c3df3824@email.android.com>
Date: Thu, 26 Jun 2014 13:12:35 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Andy Lutomirski <luto@...capital.net>,
Andi Kleen <andi@...stfloor.org>
CC: X86 ML <x86@...nel.org>,
Linux Kernel <linux-kernel@...r.kernel.org>,
Borislav Petkov <bp@...en8.de>
Subject: Re: [PATCH] x86_64,entry: Fix RCX for traced syscalls
The real question is if we care that sysret and iter don't match. On 32 bits the situation is even more complex.
On June 26, 2014 1:00:22 PM PDT, Andy Lutomirski <luto@...capital.net> wrote:
>On Thu, Jun 26, 2014 at 12:59 PM, Andy Lutomirski <luto@...capital.net>
>wrote:
>> On Thu, Jun 26, 2014 at 12:56 PM, Andi Kleen <andi@...stfloor.org>
>wrote:
>>>> show RCX == RIP even under strace.
>>>
>>> If you think it's really worth the extra instruction?
>>
>> Hard to say. That extra instruction only happens on slow paths, so I
>> suspect the slowdown is negligible. On the other hand, having
>syscall
>> show a blatant difference in behavior between traced and untraced
>> processes seems unfortunate.
>>
>>>
>>> It's not wrong, but it's not clear if it's useful.
>
>Also, if anyone ever wants to add some code to switch back from iret
>to sysret when sysret will work, this is a prerequisite. Otherwise
>sysret will never match iret. (I'm not immediately planning on doing
>this, but I can imagine workloads (e.g. UML) for which it would be a
>big improvement.)
>
>--Andy
--
Sent from my mobile phone. Please pardon brevity and lack of formatting.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists