[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrXLb+X9WrkibL+jvuYfd_Rs_N8QbXmZZdZNkk8gvLgtww@mail.gmail.com>
Date: Sun, 6 Mar 2016 08:16:21 -0800
From: Andy Lutomirski <luto@...capital.net>
To: Ingo Molnar <mingo@...nel.org>
Cc: Andrew Cooper <andrew.cooper3@...rix.com>,
Oleg Nesterov <oleg@...hat.com>,
Borislav Petkov <bp@...en8.de>,
Brian Gerst <brgerst@...il.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
X86 ML <x86@...nel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH 00/10] x86: Various SYSENTER/SYSEXIT/#DB fixes and cleanups
On Mar 6, 2016 12:31 AM, "Ingo Molnar" <mingo@...nel.org> wrote:
>
>
> * Andy Lutomirski <luto@...nel.org> wrote:
>
> > hpa asked me to get rid of the ASM_CLAC at the beginning of the SYSENTER
> > path. Little did he know...
>
> Btw., before we further change this code, something else I think would be very
> useful. We have countless system call entry points on x86 CPUs, and they are now
> consistently named and are very easy to grep for:
>
> triton:~/tip> git grep 'ENTRY(entry_' arch/x86/entry/
> arch/x86/entry/entry_32.S:ENTRY(entry_SYSENTER_32)
> arch/x86/entry/entry_32.S:ENTRY(entry_INT80_32)
> arch/x86/entry/entry_64.S:ENTRY(entry_SYSCALL_64)
> arch/x86/entry/entry_64_compat.S:ENTRY(entry_SYSENTER_compat)
> arch/x86/entry/entry_64_compat.S:ENTRY(entry_SYSCALL_compat)
> arch/x86/entry/entry_64_compat.S:ENTRY(entry_INT80_compat)
>
> Furthermore, each entry point has extensive comments, except one important detail:
> none of the comments really explains the circumstances under which the entry
> points are _used_ by user-space.
>
> I'd like to see something like:
>
> arch/x86/entry/entry_64.S:ENTRY(entry_SYSCALL_64)
>
> *
> * The 64-bit SYSCALL instruction is used by all modern 64-bit user-space
> * code to execute most system calls: this instruction is the fastest and
> * sanest implementation on modern Intel and AMD CPUs.
> *
>
> ... and we should add similar explanations for all of the 6 entry points, with
> caveats and limitations listed generously.
>
> Especially valuable would be to list eventual 'strange' usages of the various
> syscall instructions, used by rare packages, compatibility layers, emulators,
> embedded libraries, etc. (To the extent we know about them, obviously.)
I'll send a follow-up patch.
--Andy
Powered by blists - more mailing lists