lkml.org 
[lkml]   [2009]   [Sep]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 1/2] tracing: Add sysctl to enable/disable tracing on oops
From
Date
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




\
 
 \ /
  Last update: 2009-09-09 13:51    [W:0.063 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site