Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753250AbbEGKfg (ORCPT ); Thu, 7 May 2015 06:35:36 -0400 Received: from mail-wi0-f180.google.com ([209.85.212.180]:34542 "EHLO mail-wi0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752734AbbEGKf3 (ORCPT ); Thu, 7 May 2015 06:35:29 -0400 Date: Thu, 7 May 2015 12:35:23 +0200 From: Ingo Molnar To: Andy Lutomirski Cc: Rik van Riel , "linux-kernel@vger.kernel.org" , X86 ML , williams@redhat.com, Andrew Lutomirski , fweisbec@redhat.com, Peter Zijlstra , Heiko Carstens , Thomas Gleixner , Ingo Molnar , Paolo Bonzini , "Paul E. McKenney" , Linus Torvalds Subject: Re: [PATCH 3/3] context_tracking,x86: remove extraneous irq disable & enable from context tracking on syscall entry Message-ID: <20150507103523.GA14924@gmail.com> References: <20150501162109.GA1091@gmail.com> <5543A94B.3020108@redhat.com> <20150501163431.GB1327@gmail.com> <5543C05E.9040209@redhat.com> <20150501184025.GA2114@gmail.com> <5543CFE5.1030509@redhat.com> <20150502052733.GA9983@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Content-Length: 1642 Lines: 54 * Andy Lutomirski wrote: > >> [...] Also, we'd have to audit all the entries, and > >> system_call_after_swapgs currently enables interrupts early > >> enough that an interrupt before all the pushes will do > >> unpredictable things to pt_regs. > > > > An irq hardware frame won't push zero to that selector value, > > right? That's the only bad thing that would confuse the code. > > > > I think it's not quite that simple. The syscall entry looks like, > roughly: > > fix rsp; > sti; > push ss; > push rsp; > push flags; > push cs; > push rip; > > We can get an interrupt part-way through those pushes. Maybe there's > no bad place where we could get an IRQ since SS is first, [...] ... and it should be covered by the 'STI window' where the instruction following a STI is still part of the irqs-off section. > [...] but this is still nasty. True. Another approach would be to set up two aliases in the GDT, so we could freely change 'ss' between them and thus store information, without possibly confusing the syscall entry/exit code. That still gets complicated by IST entries, which creates multiple positions for the 'flag'. > I think I prefer a per-cpu approach over a per-task approach, since > it's easier to reason about and it should still only require one > instruction on entry and one instruction on exit. Yes, agreed. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/