[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180128092914.dabnzq7arv4bebhn@gmail.com>
Date: Sun, 28 Jan 2018 10:29:14 +0100
From: Ingo Molnar <mingo@...nel.org>
To: Dan Williams <dan.j.williams@...el.com>
Cc: 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
* 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>
Thanks,
Ingo
Powered by blists - more mailing lists