Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754527AbbGWVy6 (ORCPT ); Thu, 23 Jul 2015 17:54:58 -0400 Received: from mail-ig0-f176.google.com ([209.85.213.176]:36839 "EHLO mail-ig0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754043AbbGWVyy (ORCPT ); Thu, 23 Jul 2015 17:54:54 -0400 MIME-Version: 1.0 In-Reply-To: References: <20150723212042.GN25159@twins.programming.kicks-ass.net> Date: Thu, 23 Jul 2015 14:54:54 -0700 X-Google-Sender-Auth: bHqnuB0cKwASGJHGdH5PQC5xAKQ Message-ID: Subject: Re: Dealing with the NMI mess From: Linus Torvalds To: Andy Lutomirski Cc: Peter Zijlstra , X86 ML , "linux-kernel@vger.kernel.org" , Willy Tarreau , Borislav Petkov , Thomas Gleixner , Steven Rostedt , Brian Gerst Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1698 Lines: 36 On Thu, Jul 23, 2015 at 2:45 PM, Andy Lutomirski wrote: > > Or we just re-enable them on the way out of NMI (i.e. the very last > thing we do in the NMI handler). I don't want to break regular > userspace gdb when perf is running. I'd really prefer it if we don't touch NMI code in those kinds of ways. The NMI code is fragile as hell. All the problems we have with it is exactly due to "where is the boundary" issues. That's why I *don't* want NMI code to do magic crap. Anything that says "disable this during this magic window" is broken. The problems we've had are exactly about atomicity of the entry/exit conditions, and there is no really good way to get them right. I'd be much happier with a _TIF_USER_WORK_MASK approach exactly because it's so *obvious* that it's not a boundary condition. I dislike the "disable and re-enable dr7 in the NMI handler" exactly because it smells like "we can only handle faults in _this_ region". It may be true, but it's also what I want us to get away from. I'd much rather have the "big picture" be that we can take faults anywhere at all (*), and that none of the core code really cares. Then we "fix up" user space. Linus (*) And yes, sysenter and not having a stack at all is very special, and I think we will *always* have to have that magical special case of the first few instructions there. But that's a separate hardware limitation we can't get around. -- 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/