Messages in this thread | | | Subject | Re: [PATCH 1/2] tracing: Add sysctl to enable/disable tracing on oops | From | Steven Rostedt <> | Date | Wed, 09 Sep 2009 07:48:05 -0400 |
| |
On Wed, 2009-09-09 at 13:19 +0900, KOSAKI Motohiro wrote: > > On Wed, 2009-09-09 at 10:40 +0800, Li Zefan wrote: > > > > > > I have another silly question. > > > > Why should we call tracing_off() in oops_enter()? > > > > > > > > > > I guess it's because trace outputs generated during oops can > > > overwrite/mess up those generated before oops? > > > > > > It was added by this commit, but I can't find trace_printk_on_oops. > > > > That's because Thomas did not bother looking up the actual variable he > > was talking about. s/trace_printk_on_oops/ftrace_dump_on_oops/ > > After a bit thinking, I think ftrace_dump_on_oops and kernel dump with panic have > very similar requirement. > Then, I think we can reuse this infrastructure for kernel dump. > > Requirement > - Need to know why the problem occur. > - Need to don't logging oops (panic) internal. > > Unfortunately, panic() call panic_notifier after crash_kexec(). > it mean tracing_off() was not called when panic on the machine w/ kernel-dump. > > NORET_TYPE void panic(const char * fmt, ...) > { > (snip) > crash_kexec(NULL); > (snip) > atomic_notifier_call_chain(&panic_notifier_list, 0, buf); > > I think we can insert tracing_off() into panic() directly. it only > bit mask operation, it mean it don't have side effect risk. > > Perhaps, There are other kernel dump specific requrement. but I guess > it's very small. Maybe it can be handled by trace_die_handler() or something like. > > What do you think?
Yes, a tracing_off() should be in the beginning of panic. I had a patch to do this, but I never sent it out :-/
-- Steve
| |