[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrVLFtg=VqYTaBenD+U9uQJENTZx7Nd30LVsQg7HQ_ydrQ@mail.gmail.com>
Date: Wed, 3 Dec 2014 17:42:28 -0800
From: Andy Lutomirski <luto@...capital.net>
To: X86 ML <x86@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>,
"H. Peter Anvin" <hpa@...or.com>, Eric Paris <eparis@...hat.com>,
Richard Guy Briggs <rgb@...hat.com>
Cc: Frédéric Weisbecker <fweisbec@...il.com>,
Oleg Nesterov <oleg@...hat.com>,
kvm list <kvm@...r.kernel.org>,
Andy Lutomirski <luto@...capital.net>
Subject: Re: [PATCH 0/3] x86_64,entry: Rearrange the syscall exit optimizations
[adding potentially interested people]
On Fri, Nov 7, 2014 at 3:58 PM, Andy Lutomirski <luto@...capital.net> wrote:
> The syscall exit asm is a big mess. There's a really fast path, some
> kind of fast path code (with a hard-coded optimization for audit), and
> the really slow path. The result is that it's very hard to work with
> this code. There are some asm paths that are much slower than they
> should be (context tracking is a major offender), but no one really
> wants to add even more asm to speed them up.
>
> This series takes a different, unorthodox approach. Rather than trying
> to avoid entering the very slow iret path, it adds a way back out of the
> iret path. The result is a dramatic speedup for context tracking, user
> return notification, and similar code, as the cost of a few lines of
> tricky asm. Nonetheless, it's barely a net addition of asm code,
> because we get to remove the fast path optimizations for audit and
> rescheduling.
>
> Thoughts? If this works, it opens the door for a lot of further
> consolidation of the exit code.
>
> Note: patch 1 in this series has been floating around on the list
> for quite a while. It's mandatory for this series to work, because
> the buglet that it fixes almost completely defeats the optimization
> that I'm introducing.
It turns out that sysret_audit may be rather buggy. I think it leaves
edx and edi in a confused state, and it interacts badly with
SCHEDULE_USER if context tracking is on. My preferred long-term
solution is to delete sysret_audit entirely, which this patch set
does. Can you (x86 people and people who, for reasons that escape me,
enjoy reviewing this stuff) take a look?
This clearly isn't 3.18 material, and it may want to soak in -next
(can -tip do that? I can do it myself, I suppose), but it might also
be a good idea to try to do this for 3.19 to get rid of sysret_audit.
For those who haven't followed all the recent threads: the asm that's
deleted in patch 3 currently has a nasty RCU + context tracking +
audit bug that has become much easier to trigger as a result of the
seccomp changes in 3.18. This isn't directly a bug in the seccomp
changes -- it's just that the seccomp changes make it much easier to
cause the offending ask to be executed.
--Andy
>
> Andy Lutomirski (3):
> x86_64,entry: Fix RCX for traced syscalls
> x86_64,entry: Use sysret to return to userspace when possible
> x86_64,entry: Remove the syscall exit audit and schedule optimizations
>
> arch/x86/kernel/entry_64.S | 103 ++++++++++++++++++++++++---------------------
> 1 file changed, 55 insertions(+), 48 deletions(-)
>
> --
> 1.9.3
>
--
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists