lkml.org 
[lkml]   [2011]   [Dec]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC][PATCH 5/5 v2] x86: Allow NMIs to hit breakpoints in i386
* Steven Rostedt (rostedt@goodmis.org) wrote:
[...]> From: Steven Rostedt <srostedt@redhat.com>
> +#define nmi_preprocess(regs) \
> + do { \
> + if (__get_cpu_var(nmi_state) != NMI_NOT_RUNNING) { \
> + __get_cpu_var(nmi_state) = NMI_LATCHED; \
> + return; \
> + } \
> + nmi_restart: \
> + __get_cpu_var(nmi_state) = NMI_EXECUTING; \
> + } while (0)
> +
> +#define nmi_postprocess() \
> + do { \
> + if (cmpxchg(&__get_cpu_var(nmi_state), \
> + NMI_EXECUTING, NMI_NOT_RUNNING) != NMI_EXECUTING) \
> + goto nmi_restart; \
> + } while (0)
> +
[...]
> +dotraplinkage notrace __kprobes void
> +do_nmi(struct pt_regs *regs, long error_code)
> +{
> + nmi_preprocess(regs);
> +
> nmi_enter();
>
> inc_irq_stat(__nmi_count);
> @@ -428,8 +515,7 @@ do_nmi(struct pt_regs *regs, long error_code)
>
> nmi_exit();
>
> - if (unlikely(update_debug_stack))
> - reset_debug_stack();
> + nmi_postprocess();

Just to make sure I understand: if an NMI nests over do_nmi between
nmi_postprocess() and the following iret (in which case the CPU is in
state NMI_NOT_RUNNING), we will end up with two NMI handlers nested on
the stack, right ? Given that there is no upper-bound on the nesting
level of this situation (although nesting like this more than once is
extremely unlikely), is this side-effect something we should care about
in terms of stack space usage ? Also, is the stack dump OOPS handler
aware of this stack layout that was until now impossible ?

Thanks,

Mathieu

> }
>
> void stop_nmi(void)
> --
> 1.7.7.3
>
>

--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com


\
 
 \ /
  Last update: 2011-12-14 14:33    [W:0.103 / U:0.208 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site