[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 28 Jan 2018 07:22:26 -0800
From: Andy Lutomirski <luto@...capital.net>
To: Ingo Molnar <mingo@...nel.org>
Cc: Dan Williams <dan.j.williams@...el.com>, tglx@...utronix.de,
linux-arch@...r.kernel.org, kernel-hardening@...ts.openwall.com,
gregkh@...uxfoundation.org, x86@...nel.org, Ingo Molnar <mingo@...hat.com>,
Andy Lutomirski <luto@...nel.org>, "H. Peter Anvin" <hpa@...or.com>,
torvalds@...ux-foundation.org, alan@...ux.intel.com,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 07/12] x86: remove the syscall_64 fast-path
> On Jan 28, 2018, at 1:29 AM, Ingo Molnar <mingo@...nel.org> wrote:
>
>
> * Dan Williams <dan.j.williams@...el.com> wrote:
>
>> Quoting Linus:
>>
>> "Honestly, I'd rather get rid of the fast-path entirely. Compared to
>> all the PTI mess, it's not even noticeable.
>>
>> And if we ever get CPU's that have this all fixed, we can re-visit
>> introducing the fastpath. But this is all very messy and it doesn't
>> seem worth it right now.
>>
>> If we get rid of the fastpath, we can lay out the slow path slightly
>> better, and get rid of some of those jump-overs. And we'd get rid of
>> the ptregs hooks entirely.
>>
>> So we can try to make the "slow" path better while at it, but I
>> really don't think it matters much now in the post-PTI era. Sadly."
>
> Please fix the title to have the proper prefix and to reference the function that
> is actually modified by the patch, i.e. something like:
>
> s/ x86: remove the syscall_64 fast-path
> / x86/entry/64: Remove the entry_SYSCALL_64() fast-path
>
> With the title fixed:
>
> Reviewed-by: Ingo Molnar <mingo@...nel.org>
I have a very similar but not quite identical version I'll send out shortly. The difference is that I fixed the silly prologue.
>
> Thanks,
>
> Ingo
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
