[ltt-dev] [PATCH v2] add tracepoints of panic and kexec

Mathieu Desnoyers compudj at krystal.dyndns.org
Thu Feb 19 01:13:44 EST 2009


* Mathieu Desnoyers (compudj at krystal.dyndns.org) wrote:
> * Zhaolei (zhaolei at cn.fujitsu.com) wrote:
> > * From: "Mathieu Desnoyers" <mathieu.desnoyers at polymtl.ca>
> > >* Zhaolei (zhaolei at cn.fujitsu.com) wrote:
> > >> * From: "Mathieu Desnoyers" <compudj at krystal.dyndns.org>
> > >> >* Zhaolei (zhaolei at cn.fujitsu.com) wrote:
> > >> >> Instrumentation of following panic and kexec related events are added:
> > >> >> panic
> > >> >> kernel_kexec
> > >> >> crash_kexec
> > >> >> 
> > >> >> It is useful for build flight-recorder program based on lttng infrastructure.
> > >> >> 
> > >> > 
> > >> > Hrm, I'm wondering if these are events we are interested to trace or if
> > >> > you plan to use these tracepoints as hooks into the kernel to connect
> > >> > the tracer infrastructure to it ?
> > >> Hello, Mathieu
> > >> 
> > >> IMHO, both.
> > >> 
> > >> As a programmer who want to build  flight-recorder based on lttng infrastructure,
> > >> he can:
> > >> 1: use lttng trace, and get lttng's trace datas from kernel-dump file.
> > >> or
> > >> 2: use lttng's tracepoint, and record events himself.
> > >> 
> > >> But as a lttng's programmer, we can make both way possible.
> > >> 
> > >> What is your opinion?
> > >> 
> > > 
> > > Hi Zhaolei,
> > > 
> > > I think having the tracepoints for panic and kexec would be a good
> > > start. 
> > Hello, Mathieu
> > 
> > Glad to hear that.
> > 
> > > Then whenever we need more specific hooks to send the data out
> > > (for crash data extraction), we can add notification hooks at that time.
> > > Do you have an updated version of panic+kexec instrumentation ?
> > Do you means update this patch to top of lttng-git-tree only?
> > 
> 
> Yes,
> 
> it's possible that it directly applies, can you confirm and resend ?
> 
> Thanks,
> 

Hrm, I just had an afterthought :

Could you also provide a probe module in ltt/probes/ that would get the
data identified by these tracepoints into the trace stream ?  This would
help getting the data into the trace. Otherwise, there would be no real
user of these tracepoints.

Thanks,

MAthieu


> Mathieu
> 
> > B.R.
> > Zhaolei
> > 
> > > 
> > > Thanks,
> > > 
> > > Mathieu
> > > 
> > >> B.R.
> > >> Zhaolei
> > >> > 
> > >> > If you plan to use those as hooks into the kernel, we should probably
> > >> > consider adding notifiers instead (notifier.h). This is the "blessed"
> > >> > way to be called upon such events.
> > >> > 
> > >> > Mathieu
> > >> > 
> > >> >> Signed-off-by: Zhao Lei <zhaolei at cn.fujitsu.com>
> > >> >> ---
> > >> >>  include/trace/kernel.h |   10 ++++++++++
> > >> >>  kernel/kexec.c         |    8 ++++++++
> > >> >>  kernel/panic.c         |    7 +++++++
> > >> >>  3 files changed, 25 insertions(+), 0 deletions(-)
> > >> >> 
> > >> >> diff --git a/include/trace/kernel.h b/include/trace/kernel.h
> > >> >> index d2c3320..06d585f 100644
> > >> >> --- a/include/trace/kernel.h
> > >> >> +++ b/include/trace/kernel.h
> > >> >> @@ -2,6 +2,7 @@
> > >> >>  #define _TRACE_KERNEL_H
> > >> >>  
> > >> >>  #include <linux/tracepoint.h>
> > >> >> +#include <linux/kexec.h>
> > >> >>  
> > >> >>  DECLARE_TRACE(kernel_printk,
> > >> >>  TPPROTO(unsigned long retaddr),
> > >> >> @@ -15,5 +16,14 @@ DECLARE_TRACE(kernel_module_free,
> > >> >>  DECLARE_TRACE(kernel_module_load,
> > >> >>  TPPROTO(struct module *mod),
> > >> >>  TPARGS(mod));
> > >> >> +DECLARE_TRACE(kernel_panic,
> > >> >> + TPPROTO(const char *fmt, va_list args),
> > >> >> + TPARGS(fmt, args));
> > >> >> +DECLARE_TRACE(kernel_kernel_kexec,
> > >> >> + TPPROTO(struct kimage *image),
> > >> >> + TPARGS(image));
> > >> >> +DECLARE_TRACE(kernel_crash_kexec,
> > >> >> + TPPROTO(struct kimage *image, struct pt_regs *regs),
> > >> >> + TPARGS(image, regs));
> > >> >>  
> > >> >>  #endif
> > >> >> diff --git a/kernel/kexec.c b/kernel/kexec.c
> > >> >> index aef2653..56cdaac 100644
> > >> >> --- a/kernel/kexec.c
> > >> >> +++ b/kernel/kexec.c
> > >> >> @@ -30,6 +30,7 @@
> > >> >>  #include <linux/pm.h>
> > >> >>  #include <linux/cpu.h>
> > >> >>  #include <linux/console.h>
> > >> >> +#include <trace/kernel.h>
> > >> >>  
> > >> >>  #include <asm/page.h>
> > >> >>  #include <asm/uaccess.h>
> > >> >> @@ -37,6 +38,9 @@
> > >> >>  #include <asm/system.h>
> > >> >>  #include <asm/sections.h>
> > >> >>  
> > >> >> +DEFINE_TRACE(kernel_kernel_kexec);
> > >> >> +DEFINE_TRACE(kernel_crash_kexec);
> > >> >> +
> > >> >>  /* Per cpu memory for storing cpu states in case of system crash. */
> > >> >>  note_buf_t* crash_notes;
> > >> >>  
> > >> >> @@ -1062,6 +1066,8 @@ asmlinkage long compat_sys_kexec_load(unsigned long entry,
> > >> >>  
> > >> >>  void crash_kexec(struct pt_regs *regs)
> > >> >>  {
> > >> >> + trace_kernel_crash_kexec(kexec_crash_image, regs);
> > >> >> +
> > >> >>  /* Take the kexec_mutex here to prevent sys_kexec_load
> > >> >>  * running on one cpu from replacing the crash kernel
> > >> >>  * we are using after a panic on a different cpu.
> > >> >> @@ -1428,6 +1434,8 @@ int kernel_kexec(void)
> > >> >>  {
> > >> >>  int error = 0;
> > >> >>  
> > >> >> + trace_kernel_kernel_kexec(kexec_image);
> > >> >> +
> > >> >>  if (!mutex_trylock(&kexec_mutex))
> > >> >>  return -EBUSY;
> > >> >>  if (!kexec_image) {
> > >> >> diff --git a/kernel/panic.c b/kernel/panic.c
> > >> >> index 12c5a0a..3fa642e 100644
> > >> >> --- a/kernel/panic.c
> > >> >> +++ b/kernel/panic.c
> > >> >> @@ -21,6 +21,9 @@
> > >> >>  #include <linux/debug_locks.h>
> > >> >>  #include <linux/random.h>
> > >> >>  #include <linux/kallsyms.h>
> > >> >> +#include <trace/kernel.h>
> > >> >> +
> > >> >> +DEFINE_TRACE(kernel_panic);
> > >> >>  
> > >> >>  int panic_on_oops;
> > >> >>  int tainted;
> > >> >> @@ -68,6 +71,10 @@ NORET_TYPE void panic(const char * fmt, ...)
> > >> >>  unsigned long caller = (unsigned long) __builtin_return_address(0);
> > >> >>  #endif
> > >> >>  
> > >> >> + va_start(args, fmt);
> > >> >> + trace_kernel_panic(fmt, args);
> > >> >> + va_end(args);
> > >> >> +
> > >> >>  /*
> > >> >>  * It's possible to come here directly from a panic-assertion and not
> > >> >>  * have preempt disabled. Some functions called from here want
> > >> >> -- 
> > >> >> 1.5.5.3
> > >> >> 
> > >> >> 
> > >> >> 
> > >> >> _______________________________________________
> > >> >> ltt-dev mailing list
> > >> >> ltt-dev at lists.casi.polymtl.ca
> > >> >> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
> > >> >> 
> > >> > 
> > >> > -- 
> > >> > Mathieu Desnoyers
> > >> > OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
> > >> > 
> > >> >
> > >> 
> > > 
> > > -- 
> > > Mathieu Desnoyers
> > > OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
> > > 
> > >
> > _______________________________________________
> > ltt-dev mailing list
> > ltt-dev at lists.casi.polymtl.ca
> > http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
> > 
> 
> -- 
> Mathieu Desnoyers
> OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
> 
> _______________________________________________
> ltt-dev mailing list
> ltt-dev at lists.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
> 

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68




More information about the lttng-dev mailing list