From: Ingo Molnar <mingo@kernel.org>
To: Andy Lutomirski <luto@kernel.org>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
Borislav Petkov <bp@alien8.de>, Oleg Nesterov <oleg@redhat.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Brian Gerst <brgerst@gmail.com>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH 00/10] x86: Various SYSENTER/SYSEXIT/#DB fixes and cleanups
Date: Sun, 6 Mar 2016 09:31:19 +0100 [thread overview]
Message-ID: <20160306083119.GB12352@gmail.com> (raw)
In-Reply-To: <cover.1457243356.git.luto@kernel.org>
* Andy Lutomirski <luto@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.e. it would be very nice to do a full documentation of our current system call
usage patterns, as utilized by user-space. Beyond the documentation value this
will also help people prioritize optimizations between the various entry points -
which should be optimized more, which entry point matters less, etc.
Thanks,
Ingo
next prev parent reply other threads:[~2016-03-06 8:31 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-06 5:52 [PATCH 00/10] x86: Various SYSENTER/SYSEXIT/#DB fixes and cleanups Andy Lutomirski
2016-03-06 5:52 ` [PATCH v2 01/10] selftests/x86: In syscall_nt, test NT|TF as well Andy Lutomirski
2016-03-06 5:52 ` [PATCH v2 02/10] x86/entry/compat: In SYSENTER, sink AC clearing below the existing FLAGS test Andy Lutomirski
2016-03-06 5:52 ` [PATCH v2 03/10] x86/entry/32: Filter NT and speed up AC filtering in SYSENTER Andy Lutomirski
2016-03-06 5:52 ` [PATCH v2 04/10] x86/entry/32: Restore FLAGS on SYSEXIT Andy Lutomirski
2016-03-06 5:52 ` [PATCH v2 05/10] x86/traps: Clear TIF_BLOCKSTEP on all debug exceptions Andy Lutomirski
2016-03-06 5:52 ` [PATCH v2 06/10] x86/traps: Clear DR6 early in do_debug and improve the comment Andy Lutomirski
2016-03-06 5:52 ` [PATCH v2 07/10] x86/entry: Vastly simplify SYSENTER TF handling Andy Lutomirski
2016-03-06 16:55 ` Borislav Petkov
2016-03-06 17:30 ` Brian Gerst
2016-03-06 17:36 ` Andy Lutomirski
2016-03-06 18:01 ` Borislav Petkov
2016-03-06 18:20 ` Andrew Cooper
2016-03-07 17:17 ` Brian Gerst
2016-03-07 18:03 ` Andy Lutomirski
2016-03-07 18:41 ` Brian Gerst
2016-03-07 18:46 ` Andy Lutomirski
2016-03-06 5:52 ` [PATCH v2 08/10] x86/entry: Only allocate space for SYSENTER_stack if needed Andy Lutomirski
2016-03-06 5:52 ` [PATCH v2 09/10] x86/entry/32: Simplify and fix up the SYSENTER stack #DB/NMI fixup Andy Lutomirski
2016-03-08 6:36 ` Borislav Petkov
2016-03-06 5:52 ` [PATCH v2 10/10] x86/entry/32: Add and check a stack canary for the SYSENTER stack Andy Lutomirski
2016-03-08 6:40 ` Borislav Petkov
2016-03-09 21:22 ` Andy Lutomirski
2016-03-06 8:22 ` [PATCH 00/10] x86: Various SYSENTER/SYSEXIT/#DB fixes and cleanups Ingo Molnar
2016-03-06 16:16 ` Andy Lutomirski
2016-03-07 8:29 ` Ingo Molnar
2016-03-06 8:31 ` Ingo Molnar [this message]
2016-03-06 16:16 ` Andy Lutomirski
-- strict thread matches above, loose matches on Subject: below --
2016-02-29 5:28 Andy Lutomirski
2016-02-29 18:55 ` Andy Lutomirski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160306083119.GB12352@gmail.com \
--to=mingo@kernel.org \
--cc=andrew.cooper3@citrix.com \
--cc=bp@alien8.de \
--cc=brgerst@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=oleg@redhat.com \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).