On Fri, 2010-01-15 at 08:03 -0600, Jason Wessel wrote: > 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.
Ah, if this is done by stopping the box, then it should be pretty safe. There's two other ways that tracing can be enabled. One, if someone modifies the kernel and adds "tracing_on()" somewhere. Which, if happens, is the users fault. You change the kernel, you are responsible for the consequences. The other, which can happen from user land, is the "function:traceon" feature. # echo 'schedule:traceon' > /sys/kernel/debug/tracing/set_ftrace_filter This will not add schedule to the ftrace filter, but instead it will attach a check to schedule that will make the tracer enabled. If someone attaches a "traceon" command to a function that might be called by the kernel debugger, then you may have an issue. But this too, may just be blamed on the user. -- Steve ------------------------------------------------------------------------------ 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
