From mboxrd@z Thu Jan 1 00:00:00 1970 From: zhaolei@cn.fujitsu.com (Zhaolei) Date: Thu, 19 Feb 2009 13:31:31 +0800 Subject: [ltt-dev] [PATCH v2] add tracepoints of panic and kexec References: <4949BD17.2000704@cn.fujitsu.com> <4949BD46.3020806@cn.fujitsu.com> <20081218041402.GA21563@Krystal> <4949E1C3.7000308@cn.fujitsu.com> <4949E1F1.7020505@cn.fujitsu.com> <20081218184745.GA20815@Krystal> <62826BBD9D1A43129074C551483312DB@zhaoleiwin> <20090219041446.GG7956@Krystal> Message-ID: <1C905F9460BC4F218C818534FE8F9176@zhaoleiwin> * From: "Mathieu Desnoyers" >* Zhaolei (zhaolei at cn.fujitsu.com) wrote: >> * From: "Mathieu Desnoyers" >> >* 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? 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 >> >> --- >> >> 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 >> >> +#include >> >> >> >> 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 >> >> #include >> >> #include >> >> +#include >> >> >> >> #include >> >> #include >> >> @@ -37,6 +38,9 @@ >> >> #include >> >> #include >> >> >> >> +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 >> >> #include >> >> #include >> >> +#include >> >> + >> >> +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 > >