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

[zhaolei@cn.fujitsu.com (Zhaolei)]

* From: "Mathieu Desnoyers" <compudj@krystal.dyndns.org>
>* Mathieu Desnoyers (compudj at krystal.dyndns.org) wrote:
>> * Zhaolei (zhaolei at cn.fujitsu.com) wrote:
>> > * From: "Mathieu Desnoyers" <mathieu.desnoyers@polymtl.ca>
>> > >* Zhaolei (zhaolei at cn.fujitsu.com) wrote:
>> > >> * From: "Mathieu Desnoyers" <compudj@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.
Hello, Mathieu

It is useful to add marker-interface to these event.
I'll do it and send a updated patch.

B.R.
Zhaolei
> 
> 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
> 
>