From: Peter Zijlstra <peterz@infradead.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andy Lutomirski <luto@amacapital.net>, X86 ML <x86@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Willy Tarreau <w@1wt.eu>, Borislav Petkov <bp@alien8.de>,
Thomas Gleixner <tglx@linutronix.de>,
Steven Rostedt <rostedt@goodmis.org>,
Brian Gerst <brgerst@gmail.com>
Subject: Re: Dealing with the NMI mess
Date: Fri, 24 Jul 2015 13:06:39 +0200 [thread overview]
Message-ID: <20150724110639.GG19282@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <CA+55aFz6kXL2oc7QkuMnoc8cOq29R9mFhpumuifGbnJHLinzsA@mail.gmail.com>
On Thu, Jul 23, 2015 at 02:54:54PM -0700, Linus Torvalds wrote:
> On Thu, Jul 23, 2015 at 2:45 PM, Andy Lutomirski <luto@amacapital.net> 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.
A wee bit something like so?
We need the intermediate self-IPI because NMI/MCE etc do not deal with
TIF flags.
I further cleared all of DR7 in an attempt at reducing the amount of
state tracked. And it doesn't distinguish between kernel/user
watchpoints because the kernel can touch both from !IF.
---
arch/x86/kernel/traps.c | 37 +++++++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 8e65d8a9b8db..e8308e9c2b1e 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -570,6 +570,33 @@ struct bad_iret_stack *fixup_bad_iret(struct bad_iret_stack *s)
NOKPROBE_SYMBOL(fixup_bad_iret);
#endif
+struct do_debug_state {
+ unsigned long dr7;
+ struct irq_work irq_work;
+ struct callback_head task_work;
+};
+
+static void __debug_irq_trampoline(struct irq_work *work)
+{
+ struct do_debug_state *dds =
+ container_of(work, struct do_debug_state, irq_work);
+
+ task_work_add(current, &dds->task_work, true);
+}
+
+static void __debug_restore_dr7(struct callback_head *work)
+{
+ struct do_debug_state *dds =
+ container_of(work, struct do_debug_state, task_work);
+
+ set_debugreg(dds->dr7, 7);
+}
+
+static DEFINE_PER_CPU(struct do_debug_state, do_debug_state) = {
+ .irq_work = { .func = __debug_irq_trampoline, },
+ .task_work = { .func = __debug_restore_dr7, },
+};
+
/*
* Our handling of the processor debug registers is non-trivial.
* We do not clear them on entry and exit from the kernel. Therefore
@@ -603,6 +630,16 @@ dotraplinkage void do_debug(struct pt_regs *regs, long error_code)
ist_enter(regs);
+ if (arch_irqs_disabled_flags(regs->flags)) {
+ struct do_debug_state *dds = this_cpu_ptr(&do_debug_state);
+
+ get_debugreg(dds->dr7, 7);
+ set_debugreg(0, 7);
+ irq_work_queue(&dds->irq_work);
+
+ goto exit;
+ }
+
get_debugreg(dr6, 6);
/* Filter out all the reserved bits which are preset to 1 */
next prev parent reply other threads:[~2015-07-24 11:06 UTC|newest]
Thread overview: 85+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-23 20:21 Andy Lutomirski
2015-07-23 20:38 ` Linus Torvalds
2015-07-23 20:49 ` Andy Lutomirski
2015-07-23 21:08 ` Linus Torvalds
2015-07-23 21:31 ` Steven Rostedt
2015-07-23 21:46 ` Willy Tarreau
2015-07-23 21:46 ` Andy Lutomirski
2015-07-23 21:50 ` Willy Tarreau
2015-07-23 21:48 ` Linus Torvalds
2015-07-23 21:50 ` Andy Lutomirski
2015-07-23 21:59 ` Linus Torvalds
2015-07-24 8:13 ` Peter Zijlstra
2015-07-24 9:02 ` Willy Tarreau
2015-07-24 11:58 ` Steven Rostedt
2015-07-24 12:43 ` Peter Zijlstra
2015-07-24 13:03 ` Steven Rostedt
2015-07-24 13:21 ` Willy Tarreau
2015-07-24 13:30 ` Peter Zijlstra
2015-07-24 13:33 ` Peter Zijlstra
2015-07-24 14:31 ` Steven Rostedt
2015-07-24 14:59 ` Willy Tarreau
2015-07-24 15:16 ` Steven Rostedt
2015-07-24 15:26 ` Willy Tarreau
2015-07-24 15:30 ` Peter Zijlstra
2015-07-24 15:33 ` Willy Tarreau
2015-07-24 18:29 ` Linus Torvalds
2015-07-24 18:41 ` Linus Torvalds
2015-07-24 19:05 ` Steven Rostedt
2015-07-24 19:55 ` Peter Zijlstra
2015-07-24 20:22 ` Linus Torvalds
2015-07-24 20:51 ` Peter Zijlstra
2015-07-24 21:07 ` Steven Rostedt
2015-07-24 21:08 ` Andy Lutomirski
2015-07-30 15:41 ` Paolo Bonzini
2015-07-30 21:22 ` Andy Lutomirski
2015-07-30 21:58 ` Brian Gerst
2015-07-30 22:59 ` Thomas Gleixner
2015-07-31 4:22 ` Borislav Petkov
2015-07-31 5:11 ` Andy Lutomirski
2015-07-31 7:51 ` Paolo Bonzini
2015-07-31 8:03 ` Borislav Petkov
2015-07-31 9:27 ` Paolo Bonzini
2015-07-31 10:25 ` Borislav Petkov
2015-07-31 10:26 ` Paolo Bonzini
2015-07-31 10:32 ` Borislav Petkov
2015-09-07 5:39 ` Maciej W. Rozycki
2015-09-07 7:42 ` Ingo Molnar
2015-09-07 8:19 ` Maciej W. Rozycki
2015-09-07 10:19 ` Paolo Bonzini
2015-09-07 17:01 ` Maciej W. Rozycki
2015-09-07 17:22 ` Andy Lutomirski
2015-09-07 19:30 ` Maciej W. Rozycki
2015-09-07 21:56 ` Andy Lutomirski
2015-09-08 16:21 ` Maciej W. Rozycki
2015-07-24 23:53 ` Linus Torvalds
2015-07-24 15:34 ` Steven Rostedt
2015-07-24 15:49 ` Willy Tarreau
2015-07-24 15:48 ` Andy Lutomirski
2015-07-24 16:02 ` Steven Rostedt
2015-07-24 16:08 ` Willy Tarreau
2015-07-24 16:31 ` Steven Rostedt
2015-07-24 16:06 ` Steven Rostedt
2015-07-24 16:25 ` Willy Tarreau
2015-07-24 17:21 ` Andy Lutomirski
2015-07-24 17:10 ` Willy Tarreau
2015-07-24 17:20 ` Andy Lutomirski
2015-07-30 15:54 ` Paolo Bonzini
2015-07-24 17:21 ` Willy Tarreau
2015-07-23 20:52 ` Willy Tarreau
2015-07-23 20:53 ` Andy Lutomirski
2015-07-23 21:07 ` Willy Tarreau
2015-07-23 21:13 ` Linus Torvalds
2015-07-23 21:18 ` Willy Tarreau
2015-07-23 21:20 ` Peter Zijlstra
2015-07-23 21:35 ` Linus Torvalds
2015-07-23 21:45 ` Andy Lutomirski
2015-07-23 21:54 ` Linus Torvalds
2015-07-23 21:59 ` Andy Lutomirski
2015-07-23 22:03 ` Linus Torvalds
2015-07-24 10:28 ` Peter Zijlstra
2015-07-24 11:06 ` Peter Zijlstra [this message]
2015-07-23 21:17 ` Peter Zijlstra
2015-07-23 21:20 ` Steven Rostedt
2015-07-23 21:46 ` Andy Lutomirski
2015-07-24 16:33 ` Raymond Jennings
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150724110639.GG19282@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=bp@alien8.de \
--cc=brgerst@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=w@1wt.eu \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®