From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753164AbbCJN1M (ORCPT ); Tue, 10 Mar 2015 09:27:12 -0400 Received: from mail-lb0-f180.google.com ([209.85.217.180]:36043 "EHLO mail-lb0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751097AbbCJN1I (ORCPT ); Tue, 10 Mar 2015 09:27:08 -0400 MIME-Version: 1.0 In-Reply-To: <20150310132147.GB26185@gmail.com> References: <1425926364-9526-1-git-send-email-dvlasenk@redhat.com> <1425926364-9526-4-git-send-email-dvlasenk@redhat.com> <20150310125151.GB21686@gmail.com> <54FEEF0D.5080505@redhat.com> <20150310132147.GB26185@gmail.com> From: Andy Lutomirski Date: Tue, 10 Mar 2015 06:26:47 -0700 Message-ID: Subject: Re: [PATCH 3/4] x86: save user rsp in pt_regs->sp on SYSCALL64 fastpath To: Ingo Molnar Cc: Denys Vlasenko , Linus Torvalds , Steven Rostedt , Borislav Petkov , "H. Peter Anvin" , Oleg Nesterov , Frederic Weisbecker , Alexei Starovoitov , Will Drewry , Kees Cook , X86 ML , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 10, 2015 at 6:21 AM, Ingo Molnar wrote: > > * Denys Vlasenko wrote: > >> > So there are now +2 instructions (5 instead of 3) in the >> > system_call path, but there are -2 instructions in the SYSRETQ >> > path, >> >> Unfortunately, no. [...] > > So I assumed that it was an equivalent transformation, given that none > of the changelogs spelled out the increase in overhead ... > >> [...] There is only this change in SYSRETQ path, which simply >> changes where we get RSP from: >> >> @@ -293,7 +289,7 @@ ret_from_sys_call: >> CFI_REGISTER rip,rcx >> movq EFLAGS(%rsp),%r11 >> /*CFI_REGISTER rflags,r11*/ >> - movq PER_CPU_VAR(old_rsp), %rsp >> + movq RSP(%rsp),%rsp >> /* >> * 64bit SYSRET restores rip from rcx, >> * rflags from r11 (but RF and VM bits are forced to 0), >> >> Most likely, no change in execution speed here. >> At best, it is one cycle faster somewhere in address generation unit >> because for PER_CPU_VAR() address evaluation, GS base is nonzero. >> >> Since this patch does add two extra MOVs, >> I did benchmark these patches. They add exactly one cycle >> to system call code path on my Sandy Bridge CPU. > > Hm, but that's the wrong direction, we should try to make it faster, > and to clean it up - but making it slower without really good reasons > isn't good. > > Is 'usersp' really that much of a complication? usersp is IMO tolerable. The nasty thing is the FIXUP_TOP_OF_STACK / RESTORE_TOP_OF_STACK garbage, and this patch is the main step toward killing that off completely. I've still never convinced myself that there aren't ptrace-related info leaks in there. Denys, did you ever benchmark what happens if we use push instead of mov? I bet that we get that cycle back and more, not to mention much less icache usage. The reason I think that is that this patch changes us from writing nothing to the RIP slot to writing something there. If we push our stack frame instead of moving it into place, we must write to every slot, and writing the right value is probably no more expensive than writing, say, zero (the load / forwarding units are unlikely to be very busy at that point). So this change could actually be a step toward getting faster. --Andy > > Thanks, > > Ingo -- Andy Lutomirski AMA Capital Management, LLC