From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753537AbbCYSit (ORCPT ); Wed, 25 Mar 2015 14:38:49 -0400 Received: from mail-wg0-f49.google.com ([74.125.82.49]:36392 "EHLO mail-wg0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752504AbbCYSir (ORCPT ); Wed, 25 Mar 2015 14:38:47 -0400 Date: Wed, 25 Mar 2015 19:38:42 +0100 From: Ingo Molnar To: Denys Vlasenko Cc: Linus Torvalds , Steven Rostedt , Borislav Petkov , "H. Peter Anvin" , Andy Lutomirski , Oleg Nesterov , Frederic Weisbecker , Alexei Starovoitov , Will Drewry , Kees Cook , x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] x86/asm/entry/64: do not TRACE_IRQS fast SYSRET64 path Message-ID: <20150325183842.GA9302@gmail.com> References: <1427307629-10024-1-git-send-email-dvlasenk@redhat.com> <1427307629-10024-2-git-send-email-dvlasenk@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1427307629-10024-2-git-send-email-dvlasenk@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Denys Vlasenko wrote: > SYSRET code path has a small irq-off block. > On this code path, TRACE_IRQS_ON can't be called right before interrupts > are enabled for real, we can't clobber registers there. > So current code does it earlier, in a safe place. > > But with this, TRACE_IRQS_OFF/ON frames just two fast instructions, > which is ridiculous: now most of irq-off block is _outside_ of the framing. > > Do the same thing that we do on SYSCALL entry: do not track this irq-off block, > it is very small to ever cause noticeable irq latency. > > Be careful: make sure that "jnz int_ret_from_sys_call_irqs_off" now does > invoke TRACE_IRQS_OFF - move int_ret_from_sys_call_irqs_off label before > TRACE_IRQS_OFF. > > Signed-off-by: Denys Vlasenko > CC: Linus Torvalds > CC: Steven Rostedt > CC: Ingo Molnar > CC: Borislav Petkov > CC: "H. Peter Anvin" > CC: Andy Lutomirski > CC: Oleg Nesterov > CC: Frederic Weisbecker > CC: Alexei Starovoitov > CC: Will Drewry > CC: Kees Cook > CC: x86@kernel.org > CC: linux-kernel@vger.kernel.org > --- > > Changes in v2: added comment > > arch/x86/kernel/entry_64.S | 13 +++++++------ > 1 file changed, 7 insertions(+), 6 deletions(-) > > diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S > index 9c8661c..658cf2e 100644 > --- a/arch/x86/kernel/entry_64.S > +++ b/arch/x86/kernel/entry_64.S > @@ -269,8 +269,11 @@ system_call_fastpath: > * Has incompletely filled pt_regs. > */ > LOCKDEP_SYS_EXIT > + /* > + * We do not frame this tiny irq-off block with TRACE_IRQS_OFF/ON, > + * it is too small to ever cause noticeable irq latency. * ... but if we enter the slowpath from here, we'll execute a * proper TRACE_IRQS_OFF call. > @@ -298,6 +298,7 @@ system_call_fastpath: > * 64bit SYSRET restores rip from rcx, > * rflags from r11 (but RF and VM bits are forced to 0), > * cs and ss are loaded from MSRs. > + * Restoration of rflags re-enables interrupts. > */ > USERGS_SYSRET64 Is that true even if user-space disabled irqs (via CLI) and executed a syscall while having irqs off? Thanks, Ingo