Re: [PATCH 1/2] tracing: Add sysctl to enable/disable tracing on oops

[Steven Rostedt <rostedt@goodmis.org>]

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