Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754186AbbGWVNR (ORCPT ); Thu, 23 Jul 2015 17:13:17 -0400 Received: from mail-ie0-f175.google.com ([209.85.223.175]:34771 "EHLO mail-ie0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753739AbbGWVNR (ORCPT ); Thu, 23 Jul 2015 17:13:17 -0400 MIME-Version: 1.0 In-Reply-To: <20150723205207.GA3052@1wt.eu> References: <20150723205207.GA3052@1wt.eu> Date: Thu, 23 Jul 2015 14:13:16 -0700 X-Google-Sender-Auth: yu4JX2kKLhpb2riHeT6lSBb150g Message-ID: Subject: Re: Dealing with the NMI mess From: Linus Torvalds To: Willy Tarreau Cc: Andy Lutomirski , X86 ML , "linux-kernel@vger.kernel.org" , Borislav Petkov , Thomas Gleixner , Peter Zijlstra , 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: 1248 Lines: 29 On Thu, Jul 23, 2015 at 1:52 PM, Willy Tarreau wrote: > > What's the worst case that can happen with RF cleared when returing > to user space ? Not a good idea. We are fine breaking breakpoints on the kernel ("use the tracing infrastructure instead"). Breaking it in user space is not really an option. And we really don't need to. We'd only use 'ret' when returning to kernel code. And not even for the usual case, only for the "interrupts are off" case. If somebody tries to put a breakpoint on something that is used in an irq-off situation, they are doing something very specialized, and we cna tell them: "sorry, we had to break your use case because it's crazy any other way". Those kind of people are by definition not "users". They are mucking with kernel internals. Breaking them is not a regression. Btw, we should still ask Intel for that "fast iret that doesn't re-enable NMI". So for possible future CPU's we might let people do crazy things again. Linus -- 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/