On Mar 6, 2016 12:31 AM, "Ingo Molnar" <mi...@kernel.org> wrote: > > > * Andy Lutomirski <l...@kernel.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
