Steven Rostedt wrote: > On Thu, 2010-01-14 at 08:59 -0600, Jason Wessel wrote: > >> The kernel debugger should turn off kernel tracing any time the >> debugger is active and restore it on resume. >> >> CC: Steven Rostedt <[email protected]> >> Signed-off-by: Jason Wessel <[email protected]> >> --- >> kernel/debug/debug_core.c | 8 ++++++++ >> 1 files changed, 8 insertions(+), 0 deletions(-) >> >> diff --git a/kernel/debug/debug_core.c b/kernel/debug/debug_core.c >> index 6ca3f7c..464aa65 100644 >> --- a/kernel/debug/debug_core.c >> +++ b/kernel/debug/debug_core.c >> @@ -474,6 +474,7 @@ static int kgdb_cpu_enter(struct kgdb_state *ks, struct >> pt_regs *regs) >> int sstep_tries = 100; >> int error; >> int i, cpu; >> + int trace_on = 0; >> acquirelock: >> /* >> * Interrupts will be restored by the 'trap return' code, except when >> @@ -518,6 +519,8 @@ return_normal: >> */ >> if (arch_kgdb_ops.correct_hw_break) >> arch_kgdb_ops.correct_hw_break(); >> + if (trace_on) >> + tracing_on(); >> atomic_set(&cpu_in_kgdb[cpu], 0); >> touch_softlockup_watchdog_sync(); >> clocksource_touch_watchdog(); >> @@ -592,6 +595,9 @@ return_normal: >> kgdb_single_step = 0; >> kgdb_contthread = current; >> exception_level = 0; >> + trace_on = tracing_is_on(); >> + if (trace_on) >> + tracing_off(); >> > > Hmm, what happens if tracing gets turned on by something else? Will it > break this code? If so, we may need to do something different here. >
What else do you imagine would turn on tracing, or what might break? At the point in time that this is called all the slave CPUs are rounded up, and a single CPU remains executing as the "master" cpu inside the debug core. There are two exit points from this context depending on the state of how you are resuming system, where we turn tracing back on, if it was on prior to entry to the kernel debug context. I debated about using an atomic_inc and also allowing the slave_cpu entry to turn it off, because that actually happens first, and you can actually see that in the function tracer log up to the point that the master turns off tracing. The approach employed by this patch seemed the most simplistic, and definitely stopped the trace log, while the debugger was active. This particular problem with having tracing active while in the kernel debug context was not even discovered until kdb ftdump was implemented. We don't really want to do much of anything except keep minimal HW alive while in the kernel debugger context. I am open to suggestions if you think we need something more here. I can also hard code a test if you believe there is a condition that requires some investigation. Thanks, Jason. ------------------------------------------------------------------------------ Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev _______________________________________________ Kgdb-bugreport mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
