[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFyxcKNZHXhjgYDcZA4ju5Gm8mTZQzQfYHLbAFR7rfneDw@mail.gmail.com>
Date: Thu, 23 Jul 2015 14:13:16 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Willy Tarreau <w@....eu>
Cc: Andy Lutomirski <luto@...capital.net>, X86 ML <x86@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Borislav Petkov <bp@...en8.de>,
Thomas Gleixner <tglx@...utronix.de>,
Peter Zijlstra <peterz@...radead.org>,
Steven Rostedt <rostedt@...dmis.org>,
Brian Gerst <brgerst@...il.com>
Subject: Re: Dealing with the NMI mess
On Thu, Jul 23, 2015 at 1:52 PM, Willy Tarreau <w@....eu> 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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists