[PATCH]: add dmesg log symbols to /proc/vmcoreinfo lists

[PATCH]: add dmesg log symbols to /proc/vmcoreinfo lists

[Neil Horman]

Hey all-
	It would be nice to be able to extract the dmesg log from a vmcore file
without needing to keep the debug symbols for the running kernel handy all the
time.  We have a facility to do this in /proc/vmcore.  This patch adds the
log_buf and log_end symbols to the vmcoreinfo area so that tools (like
makedumpfile) can easily extract the dmesg logs from a vmcore image.

Regards
Neil

Signed-off-by: Neil Horman <nhorman@tuxdriver.com>


 include/linux/kernel.h |    2 ++
 kernel/kexec.c         |    3 +++
 kernel/printk.c        |    8 ++++++++
 3 files changed, 13 insertions(+)


diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 343df9e..a7f3e8a 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -242,6 +242,7 @@ extern struct ratelimit_state printk_ratelimit_state;
 extern int printk_ratelimit(void);
 extern bool printk_timed_ratelimit(unsigned long *caller_jiffies,
 				   unsigned int interval_msec);
+void log_buf_kexec_setup(void);
 #else
 static inline int vprintk(const char *s, va_list args)
 	__attribute__ ((format (printf, 1, 0)));
@@ -253,6 +254,7 @@ static inline int printk_ratelimit(void) { return 0; }
 static inline bool printk_timed_ratelimit(unsigned long *caller_jiffies, \
 					  unsigned int interval_msec)	\
 		{ return false; }
+#define log_buf_kexec_setup() do {} while(0)
 #endif
 
 extern int printk_needs_cpu(int cpu);
diff --git a/kernel/kexec.c b/kernel/kexec.c
index 8a6d7b0..bee284d 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -1409,6 +1409,9 @@ static int __init crash_save_vmcoreinfo_init(void)
 	VMCOREINFO_OFFSET(list_head, prev);
 	VMCOREINFO_OFFSET(vm_struct, addr);
 	VMCOREINFO_LENGTH(zone.free_area, MAX_ORDER);
+#ifdef CONFIG_PRINTK
+	log_buf_kexec_setup();
+#endif
 	VMCOREINFO_LENGTH(free_area.free_list, MIGRATE_TYPES);
 	VMCOREINFO_NUMBER(NR_FREE_PAGES);
 	VMCOREINFO_NUMBER(PG_lru);
diff --git a/kernel/printk.c b/kernel/printk.c
index 69188f2..79e9e05 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -32,6 +32,7 @@
 #include <linux/security.h>
 #include <linux/bootmem.h>
 #include <linux/syscalls.h>
+#include <linux/kexec.h>
 
 #include <asm/uaccess.h>
 
@@ -136,6 +137,13 @@ static char *log_buf = __log_buf;
 static int log_buf_len = __LOG_BUF_LEN;
 static unsigned logged_chars; /* Number of chars produced since last read+clear operation */
 
+void log_buf_kexec_setup(void)
+{
+	VMCOREINFO_SYMBOL(log_buf);
+	VMCOREINFO_SYMBOL(log_end);
+}
+
+
 static int __init log_buf_len_setup(char *str)
 {
 	unsigned size = memparse(str, &str);

Re: [PATCH]: add dmesg log symbols to /proc/vmcoreinfo lists

[Simon Horman]

On Mon, Jan 19, 2009 at 04:21:27PM -0500, Neil Horman wrote:
> Hey all-
> 	It would be nice to be able to extract the dmesg log from a vmcore file
> without needing to keep the debug symbols for the running kernel handy all the
> time.  We have a facility to do this in /proc/vmcore.  This patch adds the
> log_buf and log_end symbols to the vmcoreinfo area so that tools (like
> makedumpfile) can easily extract the dmesg logs from a vmcore image.
> 
> Regards
> Neil
> 
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>

THis sounds reasonable to me.

-- 
Simon Horman
  VA Linux Systems Japan K.K., Sydney, Australia Satellite Office
  H: www.vergenet.net/~horms/             W: www.valinux.co.jp/en

Re: [PATCH]: add dmesg log symbols to /proc/vmcoreinfo lists

[Vivek Goyal]

On Mon, Jan 19, 2009 at 04:21:27PM -0500, Neil Horman wrote:
> Hey all-
> 	It would be nice to be able to extract the dmesg log from a vmcore file
> without needing to keep the debug symbols for the running kernel handy all the
> time.  We have a facility to do this in /proc/vmcore.  This patch adds the
> log_buf and log_end symbols to the vmcoreinfo area so that tools (like
> makedumpfile) can easily extract the dmesg logs from a vmcore image.
> 

It would be nice to get dmesg log if debug symbols are not around. Can't
we use System.map for getting symbol addresses? vmcoreinfo had started
small and seems to be growing now. I am thinking down the line will making
use of System.map for such cases make sense?

> Regards
> Neil
> 
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> 
> 
>  include/linux/kernel.h |    2 ++
>  kernel/kexec.c         |    3 +++
>  kernel/printk.c        |    8 ++++++++
>  3 files changed, 13 insertions(+)
> 
> 
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index 343df9e..a7f3e8a 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -242,6 +242,7 @@ extern struct ratelimit_state printk_ratelimit_state;
>  extern int printk_ratelimit(void);
>  extern bool printk_timed_ratelimit(unsigned long *caller_jiffies,
>  				   unsigned int interval_msec);
> +void log_buf_kexec_setup(void);
>  #else
>  static inline int vprintk(const char *s, va_list args)
>  	__attribute__ ((format (printf, 1, 0)));
> @@ -253,6 +254,7 @@ static inline int printk_ratelimit(void) { return 0; }
>  static inline bool printk_timed_ratelimit(unsigned long *caller_jiffies, \
>  					  unsigned int interval_msec)	\
>  		{ return false; }
> +#define log_buf_kexec_setup() do {} while(0)
>  #endif
>  
>  extern int printk_needs_cpu(int cpu);
> diff --git a/kernel/kexec.c b/kernel/kexec.c
> index 8a6d7b0..bee284d 100644
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -1409,6 +1409,9 @@ static int __init crash_save_vmcoreinfo_init(void)
>  	VMCOREINFO_OFFSET(list_head, prev);
>  	VMCOREINFO_OFFSET(vm_struct, addr);
>  	VMCOREINFO_LENGTH(zone.free_area, MAX_ORDER);
> +#ifdef CONFIG_PRINTK
> +	log_buf_kexec_setup();
> +#endif
>  	VMCOREINFO_LENGTH(free_area.free_list, MIGRATE_TYPES);
>  	VMCOREINFO_NUMBER(NR_FREE_PAGES);
>  	VMCOREINFO_NUMBER(PG_lru);
> diff --git a/kernel/printk.c b/kernel/printk.c
> index 69188f2..79e9e05 100644
> --- a/kernel/printk.c
> +++ b/kernel/printk.c
> @@ -32,6 +32,7 @@
>  #include <linux/security.h>
>  #include <linux/bootmem.h>
>  #include <linux/syscalls.h>
> +#include <linux/kexec.h>
>  
>  #include <asm/uaccess.h>
>  
> @@ -136,6 +137,13 @@ static char *log_buf = __log_buf;
>  static int log_buf_len = __LOG_BUF_LEN;
>  static unsigned logged_chars; /* Number of chars produced since last read+clear operation */
>  
> +void log_buf_kexec_setup(void)
> +{
> +	VMCOREINFO_SYMBOL(log_buf);
> +	VMCOREINFO_SYMBOL(log_end);
> +}
> +

Will it be an issue if we make log_buf and log_end non static and directly
access these in kexec.c?

Thanks
Vivek

Re: [PATCH]: add dmesg log symbols to /proc/vmcoreinfo lists

[Neil Horman]

On Tue, Jan 20, 2009 at 09:15:51AM -0500, Vivek Goyal wrote:
> On Mon, Jan 19, 2009 at 04:21:27PM -0500, Neil Horman wrote:
> > Hey all-
> > 	It would be nice to be able to extract the dmesg log from a vmcore file
> > without needing to keep the debug symbols for the running kernel handy all the
> > time.  We have a facility to do this in /proc/vmcore.  This patch adds the
> > log_buf and log_end symbols to the vmcoreinfo area so that tools (like
> > makedumpfile) can easily extract the dmesg logs from a vmcore image.
> > 
> 
> It would be nice to get dmesg log if debug symbols are not around. Can't
> we use System.map for getting symbol addresses? vmcoreinfo had started
> small and seems to be growing now. I am thinking down the line will making
> use of System.map for such cases make sense?
> 

System.map only include exported and public symbols.  log_buf and log_end are
static, and not reported in the System.map.  Its a nice idea, but not
comprehensive for everything in the kernel.

><snip>
> 
> Will it be an issue if we make log_buf and log_end non static and directly
> access these in kexec.c?
> 
I had considered that, but was a bit hesitant to do so, since it exposes the
internal implementation of the dmesg buffer.  In the event someone disables
CONFIG_PRINTK, thats just more code we need to ifdef.  With this implementation
we just stub out the log_buf_setup function, and let that be that.  It seems
more consice to me this way.

Regards
Neil

> Thanks
> Vivek
> 

Re: [PATCH]: add dmesg log symbols to /proc/vmcoreinfo lists

[Vivek Goyal]

On Tue, Jan 20, 2009 at 10:09:58AM -0500, Neil Horman wrote:
> On Tue, Jan 20, 2009 at 09:15:51AM -0500, Vivek Goyal wrote:
> > On Mon, Jan 19, 2009 at 04:21:27PM -0500, Neil Horman wrote:
> > > Hey all-
> > > 	It would be nice to be able to extract the dmesg log from a vmcore file
> > > without needing to keep the debug symbols for the running kernel handy all the
> > > time.  We have a facility to do this in /proc/vmcore.  This patch adds the
> > > log_buf and log_end symbols to the vmcoreinfo area so that tools (like
> > > makedumpfile) can easily extract the dmesg logs from a vmcore image.
> > > 
> > 
> > It would be nice to get dmesg log if debug symbols are not around. Can't
> > we use System.map for getting symbol addresses? vmcoreinfo had started
> > small and seems to be growing now. I am thinking down the line will making
> > use of System.map for such cases make sense?
> > 
> 
> System.map only include exported and public symbols.  log_buf and log_end are
> static, and not reported in the System.map.  Its a nice idea, but not
> comprehensive for everything in the kernel.
> 
> ><snip>
> > 
> > Will it be an issue if we make log_buf and log_end non static and directly
> > access these in kexec.c?
> > 
> I had considered that, but was a bit hesitant to do so, since it exposes the
> internal implementation of the dmesg buffer.  In the event someone disables
> CONFIG_PRINTK, thats just more code we need to ifdef.  With this implementation
> we just stub out the log_buf_setup function, and let that be that.  It seems
> more consice to me this way.
> 

Makes sense to me.

Acked-by: Vivek Goyal <vgoyal@redhat.com>

Thanks
Vivek

Re: [PATCH]: add dmesg log symbols to /proc/vmcoreinfo lists

[Andrew Morton]

On Tue, 20 Jan 2009 10:22:56 -0500 Vivek Goyal <vgoyal@redhat.com> wrote:

> On Tue, Jan 20, 2009 at 10:09:58AM -0500, Neil Horman wrote:
> > On Tue, Jan 20, 2009 at 09:15:51AM -0500, Vivek Goyal wrote:
> > > On Mon, Jan 19, 2009 at 04:21:27PM -0500, Neil Horman wrote:
> > > > Hey all-
> > > > 	It would be nice to be able to extract the dmesg log from a vmcore file
> > > > without needing to keep the debug symbols for the running kernel handy all the
> > > > time.  We have a facility to do this in /proc/vmcore.  This patch adds the
> > > > log_buf and log_end symbols to the vmcoreinfo area so that tools (like
> > > > makedumpfile) can easily extract the dmesg logs from a vmcore image.
> > > > 
> > > 
> > > It would be nice to get dmesg log if debug symbols are not around. Can't
> > > we use System.map for getting symbol addresses? vmcoreinfo had started
> > > small and seems to be growing now. I am thinking down the line will making
> > > use of System.map for such cases make sense?
> > > 
> > 
> > System.map only include exported and public symbols.  log_buf and log_end are
> > static, and not reported in the System.map.  Its a nice idea, but not
> > comprehensive for everything in the kernel.
> > 
> > ><snip>
> > > 
> > > Will it be an issue if we make log_buf and log_end non static and directly
> > > access these in kexec.c?
> > > 
> > I had considered that, but was a bit hesitant to do so, since it exposes the
> > internal implementation of the dmesg buffer.  In the event someone disables
> > CONFIG_PRINTK, thats just more code we need to ifdef.  With this implementation
> > we just stub out the log_buf_setup function, and let that be that.  It seems
> > more consice to me this way.
> > 
> 
> Makes sense to me.
> 
> Acked-by: Vivek Goyal <vgoyal@redhat.com>
> 

I rewrote the title to

	kexec: add dmesg log symbols to /proc/vmcoreinfo lists

it's nice to identify which subsystem is responsible for a patch.

I also did all the below.  Please check it.  (Is anyone else reading all
this stuff??)


From: Andrew Morton <akpm@linux-foundation.org>

- switch didnt-need-to-be-a-macro to inline

- Remove unneeded ifdefs (we already did that in the header)

- repair bouncy enter key

Cc: Neil Horman <nhorman@tuxdriver.com>
Cc: Simon Horman <horms@verge.net.au>
Cc: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 include/linux/kernel.h |    5 ++++-
 kernel/kexec.c         |    2 --
 kernel/printk.c        |    1 -
 3 files changed, 4 insertions(+), 4 deletions(-)

diff -puN include/linux/kernel.h~kexec-add-dmesg-log-symbols-to-proc-vmcoreinfo-lists-fix include/linux/kernel.h
--- a/include/linux/kernel.h~kexec-add-dmesg-log-symbols-to-proc-vmcoreinfo-lists-fix
+++ a/include/linux/kernel.h
@@ -254,7 +254,10 @@ static inline int printk_ratelimit(void)
 static inline bool printk_timed_ratelimit(unsigned long *caller_jiffies, \
 					  unsigned int interval_msec)	\
 		{ return false; }
-#define log_buf_kexec_setup() do {} while(0)
+
+static inline void log_buf_kexec_setup(void)
+{
+}
 #endif
 
 extern int printk_needs_cpu(int cpu);
diff -puN kernel/kexec.c~kexec-add-dmesg-log-symbols-to-proc-vmcoreinfo-lists-fix kernel/kexec.c
--- a/kernel/kexec.c~kexec-add-dmesg-log-symbols-to-proc-vmcoreinfo-lists-fix
+++ a/kernel/kexec.c
@@ -1409,9 +1409,7 @@ static int __init crash_save_vmcoreinfo_
 	VMCOREINFO_OFFSET(list_head, prev);
 	VMCOREINFO_OFFSET(vm_struct, addr);
 	VMCOREINFO_LENGTH(zone.free_area, MAX_ORDER);
-#ifdef CONFIG_PRINTK
 	log_buf_kexec_setup();
-#endif
 	VMCOREINFO_LENGTH(free_area.free_list, MIGRATE_TYPES);
 	VMCOREINFO_NUMBER(NR_FREE_PAGES);
 	VMCOREINFO_NUMBER(PG_lru);
diff -puN kernel/printk.c~kexec-add-dmesg-log-symbols-to-proc-vmcoreinfo-lists-fix kernel/printk.c
--- a/kernel/printk.c~kexec-add-dmesg-log-symbols-to-proc-vmcoreinfo-lists-fix
+++ a/kernel/printk.c
@@ -143,7 +143,6 @@ void log_buf_kexec_setup(void)
 	VMCOREINFO_SYMBOL(log_end);
 }
 
-
 static int __init log_buf_len_setup(char *str)
 {
 	unsigned size = memparse(str, &str);
_

Re: [PATCH]: add dmesg log symbols to /proc/vmcoreinfo lists

[Neil Horman]

On Tue, Jan 27, 2009 at 12:12:11AM -0800, Andrew Morton wrote:
> On Tue, 20 Jan 2009 10:22:56 -0500 Vivek Goyal <vgoyal@redhat.com> wrote:
> 
> > On Tue, Jan 20, 2009 at 10:09:58AM -0500, Neil Horman wrote:
> > > On Tue, Jan 20, 2009 at 09:15:51AM -0500, Vivek Goyal wrote:
> > > > On Mon, Jan 19, 2009 at 04:21:27PM -0500, Neil Horman wrote:
> > > > > Hey all-
> > > > > 	It would be nice to be able to extract the dmesg log from a vmcore file
> > > > > without needing to keep the debug symbols for the running kernel handy all the
> > > > > time.  We have a facility to do this in /proc/vmcore.  This patch adds the
> > > > > log_buf and log_end symbols to the vmcoreinfo area so that tools (like
> > > > > makedumpfile) can easily extract the dmesg logs from a vmcore image.
> > > > > 
> > > > 
> > > > It would be nice to get dmesg log if debug symbols are not around. Can't
> > > > we use System.map for getting symbol addresses? vmcoreinfo had started
> > > > small and seems to be growing now. I am thinking down the line will making
> > > > use of System.map for such cases make sense?
> > > > 
> > > 
> > > System.map only include exported and public symbols.  log_buf and log_end are
> > > static, and not reported in the System.map.  Its a nice idea, but not
> > > comprehensive for everything in the kernel.
> > > 
> > > ><snip>
> > > > 
> > > > Will it be an issue if we make log_buf and log_end non static and directly
> > > > access these in kexec.c?
> > > > 
> > > I had considered that, but was a bit hesitant to do so, since it exposes the
> > > internal implementation of the dmesg buffer.  In the event someone disables
> > > CONFIG_PRINTK, thats just more code we need to ifdef.  With this implementation
> > > we just stub out the log_buf_setup function, and let that be that.  It seems
> > > more consice to me this way.
> > > 
> > 
> > Makes sense to me.
> > 
> > Acked-by: Vivek Goyal <vgoyal@redhat.com>
> > 
> 
> I rewrote the title to
> 
> 	kexec: add dmesg log symbols to /proc/vmcoreinfo lists
> 
> it's nice to identify which subsystem is responsible for a patch.
> 
> I also did all the below.  Please check it.  (Is anyone else reading all
> this stuff??)
> 
> 
Hey Andrew-
	Yes, that all looks fine, thank.  I'm not sure of the advantage of an
inline over a #define in the event that CONFIG_PRINTK isn't defined, but its
fine with me either way.

Much appreciated!
Neil

> 

Re: [PATCH]: add dmesg log symbols to /proc/vmcoreinfo lists

[Vivek Goyal]

On Tue, Jan 27, 2009 at 12:12:11AM -0800, Andrew Morton wrote:
> On Tue, 20 Jan 2009 10:22:56 -0500 Vivek Goyal <vgoyal@redhat.com> wrote:
> 
> > On Tue, Jan 20, 2009 at 10:09:58AM -0500, Neil Horman wrote:
> > > On Tue, Jan 20, 2009 at 09:15:51AM -0500, Vivek Goyal wrote:
> > > > On Mon, Jan 19, 2009 at 04:21:27PM -0500, Neil Horman wrote:
> > > > > Hey all-
> > > > > 	It would be nice to be able to extract the dmesg log from a vmcore file
> > > > > without needing to keep the debug symbols for the running kernel handy all the
> > > > > time.  We have a facility to do this in /proc/vmcore.  This patch adds the
> > > > > log_buf and log_end symbols to the vmcoreinfo area so that tools (like
> > > > > makedumpfile) can easily extract the dmesg logs from a vmcore image.
> > > > > 
> > > > 
> > > > It would be nice to get dmesg log if debug symbols are not around. Can't
> > > > we use System.map for getting symbol addresses? vmcoreinfo had started
> > > > small and seems to be growing now. I am thinking down the line will making
> > > > use of System.map for such cases make sense?
> > > > 
> > > 
> > > System.map only include exported and public symbols.  log_buf and log_end are
> > > static, and not reported in the System.map.  Its a nice idea, but not
> > > comprehensive for everything in the kernel.
> > > 
> > > ><snip>
> > > > 
> > > > Will it be an issue if we make log_buf and log_end non static and directly
> > > > access these in kexec.c?
> > > > 
> > > I had considered that, but was a bit hesitant to do so, since it exposes the
> > > internal implementation of the dmesg buffer.  In the event someone disables
> > > CONFIG_PRINTK, thats just more code we need to ifdef.  With this implementation
> > > we just stub out the log_buf_setup function, and let that be that.  It seems
> > > more consice to me this way.
> > > 
> > 
> > Makes sense to me.
> > 
> > Acked-by: Vivek Goyal <vgoyal@redhat.com>
> > 
> 
> I rewrote the title to
> 
> 	kexec: add dmesg log symbols to /proc/vmcoreinfo lists
> 
> it's nice to identify which subsystem is responsible for a patch.
> 
> I also did all the below.  Please check it.  (Is anyone else reading all
> this stuff??)
> 
> 
> From: Andrew Morton <akpm@linux-foundation.org>
> 
> - switch didnt-need-to-be-a-macro to inline
> 
> - Remove unneeded ifdefs (we already did that in the header)
> 
> - repair bouncy enter key
> 
> Cc: Neil Horman <nhorman@tuxdriver.com>
> Cc: Simon Horman <horms@verge.net.au>
> Cc: Vivek Goyal <vgoyal@redhat.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
> 
Hi Andrew,

This looks good. I should have altleast caught unnecessary #ifdefs.:-(

Thanks
Vivek
 
>  include/linux/kernel.h |    5 ++++-
>  kernel/kexec.c         |    2 --
>  kernel/printk.c        |    1 -
>  3 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff -puN include/linux/kernel.h~kexec-add-dmesg-log-symbols-to-proc-vmcoreinfo-lists-fix include/linux/kernel.h
> --- a/include/linux/kernel.h~kexec-add-dmesg-log-symbols-to-proc-vmcoreinfo-lists-fix
> +++ a/include/linux/kernel.h
> @@ -254,7 +254,10 @@ static inline int printk_ratelimit(void)
>  static inline bool printk_timed_ratelimit(unsigned long *caller_jiffies, \
>  					  unsigned int interval_msec)	\
>  		{ return false; }
> -#define log_buf_kexec_setup() do {} while(0)
> +
> +static inline void log_buf_kexec_setup(void)
> +{
> +}
>  #endif
>  
>  extern int printk_needs_cpu(int cpu);
> diff -puN kernel/kexec.c~kexec-add-dmesg-log-symbols-to-proc-vmcoreinfo-lists-fix kernel/kexec.c
> --- a/kernel/kexec.c~kexec-add-dmesg-log-symbols-to-proc-vmcoreinfo-lists-fix
> +++ a/kernel/kexec.c
> @@ -1409,9 +1409,7 @@ static int __init crash_save_vmcoreinfo_
>  	VMCOREINFO_OFFSET(list_head, prev);
>  	VMCOREINFO_OFFSET(vm_struct, addr);
>  	VMCOREINFO_LENGTH(zone.free_area, MAX_ORDER);
> -#ifdef CONFIG_PRINTK
>  	log_buf_kexec_setup();
> -#endif
>  	VMCOREINFO_LENGTH(free_area.free_list, MIGRATE_TYPES);
>  	VMCOREINFO_NUMBER(NR_FREE_PAGES);
>  	VMCOREINFO_NUMBER(PG_lru);
> diff -puN kernel/printk.c~kexec-add-dmesg-log-symbols-to-proc-vmcoreinfo-lists-fix kernel/printk.c
> --- a/kernel/printk.c~kexec-add-dmesg-log-symbols-to-proc-vmcoreinfo-lists-fix
> +++ a/kernel/printk.c
> @@ -143,7 +143,6 @@ void log_buf_kexec_setup(void)
>  	VMCOREINFO_SYMBOL(log_end);
>  }
>  
> -
>  static int __init log_buf_len_setup(char *str)
>  {
>  	unsigned size = memparse(str, &str);
> _

Re: [PATCH]: add dmesg log symbols to /proc/vmcoreinfo lists

[Simon Horman]

On Tue, Jan 27, 2009 at 12:12:11AM -0800, Andrew Morton wrote:
> On Tue, 20 Jan 2009 10:22:56 -0500 Vivek Goyal <vgoyal@redhat.com> wrote:
> 
> > On Tue, Jan 20, 2009 at 10:09:58AM -0500, Neil Horman wrote:
> > > On Tue, Jan 20, 2009 at 09:15:51AM -0500, Vivek Goyal wrote:
> > > > On Mon, Jan 19, 2009 at 04:21:27PM -0500, Neil Horman wrote:
> > > > > Hey all-
> > > > > 	It would be nice to be able to extract the dmesg log from a vmcore file
> > > > > without needing to keep the debug symbols for the running kernel handy all the
> > > > > time.  We have a facility to do this in /proc/vmcore.  This patch adds the
> > > > > log_buf and log_end symbols to the vmcoreinfo area so that tools (like
> > > > > makedumpfile) can easily extract the dmesg logs from a vmcore image.
> > > > > 
> > > > 
> > > > It would be nice to get dmesg log if debug symbols are not around. Can't
> > > > we use System.map for getting symbol addresses? vmcoreinfo had started
> > > > small and seems to be growing now. I am thinking down the line will making
> > > > use of System.map for such cases make sense?
> > > > 
> > > 
> > > System.map only include exported and public symbols.  log_buf and log_end are
> > > static, and not reported in the System.map.  Its a nice idea, but not
> > > comprehensive for everything in the kernel.
> > > 
> > > ><snip>
> > > > 
> > > > Will it be an issue if we make log_buf and log_end non static and directly
> > > > access these in kexec.c?
> > > > 
> > > I had considered that, but was a bit hesitant to do so, since it exposes the
> > > internal implementation of the dmesg buffer.  In the event someone disables
> > > CONFIG_PRINTK, thats just more code we need to ifdef.  With this implementation
> > > we just stub out the log_buf_setup function, and let that be that.  It seems
> > > more consice to me this way.
> > > 
> > 
> > Makes sense to me.
> > 
> > Acked-by: Vivek Goyal <vgoyal@redhat.com>
> > 
> 
> I rewrote the title to
> 
> 	kexec: add dmesg log symbols to /proc/vmcoreinfo lists
> 
> it's nice to identify which subsystem is responsible for a patch.
> 
> I also did all the below.  Please check it.  (Is anyone else reading all
> this stuff??)

These look fine to me. Unfortunately they don't apply to the version
of Linus' tree that I have checked out and I'm away from net access
at this moment (though obviously not by the time this message reaches you).
I'll update my tree and check once I'm back online.

Eric Biederman usually watches kexec stuff. I'm pretty sure he
is on the kexec mailing list, but I've CCed him anyway.

> From: Andrew Morton <akpm@linux-foundation.org>
> 
> - switch didnt-need-to-be-a-macro to inline
> 
> - Remove unneeded ifdefs (we already did that in the header)
> 
> - repair bouncy enter key
> 
> Cc: Neil Horman <nhorman@tuxdriver.com>
> Cc: Simon Horman <horms@verge.net.au>
> Cc: Vivek Goyal <vgoyal@redhat.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
> 
>  include/linux/kernel.h |    5 ++++-
>  kernel/kexec.c         |    2 --
>  kernel/printk.c        |    1 -
>  3 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff -puN include/linux/kernel.h~kexec-add-dmesg-log-symbols-to-proc-vmcoreinfo-lists-fix include/linux/kernel.h
> --- a/include/linux/kernel.h~kexec-add-dmesg-log-symbols-to-proc-vmcoreinfo-lists-fix
> +++ a/include/linux/kernel.h
> @@ -254,7 +254,10 @@ static inline int printk_ratelimit(void)
>  static inline bool printk_timed_ratelimit(unsigned long *caller_jiffies, \
>  					  unsigned int interval_msec)	\
>  		{ return false; }
> -#define log_buf_kexec_setup() do {} while(0)
> +
> +static inline void log_buf_kexec_setup(void)
> +{
> +}
>  #endif
>  
>  extern int printk_needs_cpu(int cpu);
> diff -puN kernel/kexec.c~kexec-add-dmesg-log-symbols-to-proc-vmcoreinfo-lists-fix kernel/kexec.c
> --- a/kernel/kexec.c~kexec-add-dmesg-log-symbols-to-proc-vmcoreinfo-lists-fix
> +++ a/kernel/kexec.c
> @@ -1409,9 +1409,7 @@ static int __init crash_save_vmcoreinfo_
>  	VMCOREINFO_OFFSET(list_head, prev);
>  	VMCOREINFO_OFFSET(vm_struct, addr);
>  	VMCOREINFO_LENGTH(zone.free_area, MAX_ORDER);
> -#ifdef CONFIG_PRINTK
>  	log_buf_kexec_setup();
> -#endif
>  	VMCOREINFO_LENGTH(free_area.free_list, MIGRATE_TYPES);
>  	VMCOREINFO_NUMBER(NR_FREE_PAGES);
>  	VMCOREINFO_NUMBER(PG_lru);
> diff -puN kernel/printk.c~kexec-add-dmesg-log-symbols-to-proc-vmcoreinfo-lists-fix kernel/printk.c
> --- a/kernel/printk.c~kexec-add-dmesg-log-symbols-to-proc-vmcoreinfo-lists-fix
> +++ a/kernel/printk.c
> @@ -143,7 +143,6 @@ void log_buf_kexec_setup(void)
>  	VMCOREINFO_SYMBOL(log_end);
>  }
>  
> -
>  static int __init log_buf_len_setup(char *str)
>  {
>  	unsigned size = memparse(str, &str);
> _

-- 
Simon Horman
  VA Linux Systems Japan K.K., Sydney, Australia Satellite Office
  H: www.vergenet.net/~horms/             W: www.valinux.co.jp/en

Re: [PATCH]: add dmesg log symbols to /proc/vmcoreinfo lists

[Eric W. Biederman]

Simon Horman <horms@verge.net.au> writes:

>> I also did all the below.  Please check it.  (Is anyone else reading all
>> this stuff??)
>
> These look fine to me. Unfortunately they don't apply to the version
> of Linus' tree that I have checked out and I'm away from net access
> at this moment (though obviously not by the time this message reaches you).
> I'll update my tree and check once I'm back online.
>
> Eric Biederman usually watches kexec stuff. I'm pretty sure he
> is on the kexec mailing list, but I've CCed him anyway.

Thanks.

The question at head seems to be does it make sense to always
export log_buf and log_end in the VMCOREINFO section of the
core file we generate.

The premise of VMCOREINFO is that it gives crash or other
analysis tools enough information to pair a core dump with
a vmlinux and decipher the page table layout.  In general
things that are tricky to infer from just the core dump,
and the vmlinux.

Do log_buf and log_end fall in that category?

They are certainly important enough and they are symbols that
are tricky to find. That said I think we should also have 
this information exported so that we can get at
it with kgdb, jtag debuggers, and other weird debugging tools.
Do we have that already?  It doesn't look like it.  That
may be an argument for a different interface.

That aside we aren't currently exporting log_buf_len, so I don't
think this code works actually works.

Neil can you add a comment in kernel/printk.c of the algorithm
necessary for external tools to decode the ring buffer?

We need the comment because people working on kernel/printk.c
need to know what is happening and without having to review lots
of user space code, and we need the comment to verify that we
are exporting the right things.

Eric

Re: [PATCH]: add dmesg log symbols to /proc/vmcoreinfo lists

[Neil Horman]

> 
> That aside we aren't currently exporting log_buf_len, so I don't
> think this code works actually works.
> 
> Neil can you add a comment in kernel/printk.c of the algorithm
> necessary for external tools to decode the ring buffer?
> 
> We need the comment because people working on kernel/printk.c
> need to know what is happening and without having to review lots
> of user space code, and we need the comment to verify that we
> are exporting the right things.
> 

Ok, as per Erics comment, I've written this.  It applies on top of whats already
in your tree Andrew.  It adds some comments on the function in question so that
anyone working on printk.c will know why we're exporting their symbols.  It also
modifies slightly the symbols we are exporting so that we can handle dmesg
buffers that are longer than the standard PAGE_SIZE configuration, and lets us
detect and handle buffer wraps.

Thanks!

printk.c |   12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)

Signed-off-by: Neil Horman <nhorman@tuxdriver.com>

diff --git a/kernel/printk.c b/kernel/printk.c
index dd5cc7b..6a1163b 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -138,10 +138,20 @@ static int log_buf_len = __LOG_BUF_LEN;
 static unsigned logged_chars; /* Number of chars produced since last read+clear operation */
 
 #ifdef CONFIG_KEXEC
+/*
+ * This appends the listed symbols to /proc/vmcoreinfo
+ * /proc/vmcoreinfo is used by various utiilties, like
+ * crash and makedumpfile to obtain access to symbols that
+ * are otherwise very difficult to locate.  These symbols 
+ * are specifically used so that utilities 
+ * can access and extract the dmesg log from a vmcore file
+ * after a crash
+ */
 void log_buf_kexec_setup(void)
 {
 	VMCOREINFO_SYMBOL(log_buf);
-	VMCOREINFO_SYMBOL(log_end);
+	VMCOREINFO_SYMBOL(log_buf_len);
+	VMCOREINFO_SYMBOL(logged_chars)
 }
 #endif
 

Re: [PATCH]: add dmesg log symbols to /proc/vmcoreinfo lists

[Eric W. Biederman]

Neil Horman <nhorman@tuxdriver.com> writes:

>> 
>> That aside we aren't currently exporting log_buf_len, so I don't
>> think this code works actually works.
>> 
>> Neil can you add a comment in kernel/printk.c of the algorithm
>> necessary for external tools to decode the ring buffer?
>> 
>> We need the comment because people working on kernel/printk.c
>> need to know what is happening and without having to review lots
>> of user space code, and we need the comment to verify that we
>> are exporting the right things.
>> 
>
> Ok, as per Erics comment, I've written this.  It applies on top of whats already
> in your tree Andrew.  It adds some comments on the function in question so that
> anyone working on printk.c will know why we're exporting their symbols.  It also
> modifies slightly the symbols we are exporting so that we can handle dmesg
> buffers that are longer than the standard PAGE_SIZE configuration, and lets us
> detect and handle buffer wraps.

Looks like a good start but what is the algorithm for using the variables?
Given a kernel core file how do you extract the dmesg ring buffer?

It still does not appear obvious to me that you are extracting the
dmesg ring buffer correctly or easily.

Eric

Re: [PATCH]: add dmesg log symbols to /proc/vmcoreinfo lists

[Neil Horman]

On Wed, Feb 04, 2009 at 07:37:16AM -0800, Eric W. Biederman wrote:
> Neil Horman <nhorman@tuxdriver.com> writes:
> 
> >> 
> >> That aside we aren't currently exporting log_buf_len, so I don't
> >> think this code works actually works.
> >> 
> >> Neil can you add a comment in kernel/printk.c of the algorithm
> >> necessary for external tools to decode the ring buffer?
> >> 
> >> We need the comment because people working on kernel/printk.c
> >> need to know what is happening and without having to review lots
> >> of user space code, and we need the comment to verify that we
> >> are exporting the right things.
> >> 
> >
> > Ok, as per Erics comment, I've written this.  It applies on top of whats already
> > in your tree Andrew.  It adds some comments on the function in question so that
> > anyone working on printk.c will know why we're exporting their symbols.  It also
> > modifies slightly the symbols we are exporting so that we can handle dmesg
> > buffers that are longer than the standard PAGE_SIZE configuration, and lets us
> > detect and handle buffer wraps.
> 
> Looks like a good start but what is the algorithm for using the variables?
> Given a kernel core file how do you extract the dmesg ring buffer?
> 
Its the same as for every other symbol in vmcoreinfo:
1) kexec copies the symbol info for each symbol specified from
/sys/kernel/vmcoreinfo to an ELF note in the vmcore pre-defined header when the
kexec kernel is loaded into protected memory

2) on a crash, that ELF note is saved to the vmcore file along with the rest of
the data

3) apps (in this case makedumpfile) reads that ELF note so it knows where to
seek into the vmcore file to find the contents of that symbol.


> It still does not appear obvious to me that you are extracting the
> dmesg ring buffer correctly or easily.
> 
You know this patch doesn't do that right?  The functionality for that is in a
user app (in this case makedumpfile).  I have a patch here:
https://sourceforge.net/tracker/index.php?func=detail&aid=2521075&group_id=178938&atid=887142
for makedumpfile that uses this symbol info to extract the dmesg log quite well.
ken'ichi has an updated version to be posted soon which handles ring wrap and
log sizes > PAGE_SIZE as well.

Neil

> Eric
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
> 

Re: [PATCH]: add dmesg log symbols to /proc/vmcoreinfo lists

[Ken'ichi Ohmichi]

Hi Neil,

Thank you for a kernel patch and a makedumpfile patch.

Neil Horman wrote:
>> That aside we aren't currently exporting log_buf_len, so I don't
>> think this code works actually works.
>>
>> Neil can you add a comment in kernel/printk.c of the algorithm
>> necessary for external tools to decode the ring buffer?
>>
>> We need the comment because people working on kernel/printk.c
>> need to know what is happening and without having to review lots
>> of user space code, and we need the comment to verify that we
>> are exporting the right things.
>>
> 
> Ok, as per Erics comment, I've written this.  It applies on top of whats already
> in your tree Andrew.  It adds some comments on the function in question so that
> anyone working on printk.c will know why we're exporting their symbols.  It also
> modifies slightly the symbols we are exporting so that we can handle dmesg
> buffers that are longer than the standard PAGE_SIZE configuration, and lets us
> detect and handle buffer wraps.
> 
> Thanks!
> 
> printk.c |   12 +++++++++++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
> 
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> 
> diff --git a/kernel/printk.c b/kernel/printk.c
> index dd5cc7b..6a1163b 100644
> --- a/kernel/printk.c
> +++ b/kernel/printk.c
> @@ -138,10 +138,20 @@ static int log_buf_len = __LOG_BUF_LEN;
>  static unsigned logged_chars; /* Number of chars produced since last read+clear operation */
>  
>  #ifdef CONFIG_KEXEC
> +/*
> + * This appends the listed symbols to /proc/vmcoreinfo
> + * /proc/vmcoreinfo is used by various utiilties, like
> + * crash and makedumpfile to obtain access to symbols that
> + * are otherwise very difficult to locate.  These symbols 
> + * are specifically used so that utilities 
> + * can access and extract the dmesg log from a vmcore file
> + * after a crash
> + */
>  void log_buf_kexec_setup(void)
>  {
>  	VMCOREINFO_SYMBOL(log_buf);
> -	VMCOREINFO_SYMBOL(log_end);
> +	VMCOREINFO_SYMBOL(log_buf_len);
> +	VMCOREINFO_SYMBOL(logged_chars)
>  }
>  #endif

Please do not remove VMCOREINFO_SYMBOL(log_end), because makedumpfile
needs it for knowing the latest log offset in ring buffer of dmesg.
I updated a makedumpfile patch for handling ring buffer, and it is
possible to download the latest patch from the following site:

https://sourceforge.net/tracker2/download.php?group_id=178938&atid=887142&file_id=312113&aid=2521075


Thanks
Ken'ichi Ohmichi

Re: [PATCH]: add dmesg log symbols to /proc/vmcoreinfo lists

[Neil Horman]

On Thu, Feb 05, 2009 at 09:23:22AM +0900, Ken'ichi Ohmichi wrote:
> 
> Hi Neil,
> 
> Thank you for a kernel patch and a makedumpfile patch.
> 
> Neil Horman wrote:
> >> That aside we aren't currently exporting log_buf_len, so I don't
> >> think this code works actually works.
> >>
> >> Neil can you add a comment in kernel/printk.c of the algorithm
> >> necessary for external tools to decode the ring buffer?
> >>
> >> We need the comment because people working on kernel/printk.c
> >> need to know what is happening and without having to review lots
> >> of user space code, and we need the comment to verify that we
> >> are exporting the right things.
> >>
> > 
> > Ok, as per Erics comment, I've written this.  It applies on top of whats already
> > in your tree Andrew.  It adds some comments on the function in question so that
> > anyone working on printk.c will know why we're exporting their symbols.  It also
> > modifies slightly the symbols we are exporting so that we can handle dmesg
> > buffers that are longer than the standard PAGE_SIZE configuration, and lets us
> > detect and handle buffer wraps.
> > 
> > Thanks!
> > 
> > printk.c |   12 +++++++++++-
> > 1 file changed, 11 insertions(+), 1 deletion(-)
> > 
> > Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> > 
> > diff --git a/kernel/printk.c b/kernel/printk.c
> > index dd5cc7b..6a1163b 100644
> > --- a/kernel/printk.c
> > +++ b/kernel/printk.c
> > @@ -138,10 +138,20 @@ static int log_buf_len = __LOG_BUF_LEN;
> >  static unsigned logged_chars; /* Number of chars produced since last read+clear operation */
> >  
> >  #ifdef CONFIG_KEXEC
> > +/*
> > + * This appends the listed symbols to /proc/vmcoreinfo
> > + * /proc/vmcoreinfo is used by various utiilties, like
> > + * crash and makedumpfile to obtain access to symbols that
> > + * are otherwise very difficult to locate.  These symbols 
> > + * are specifically used so that utilities 
> > + * can access and extract the dmesg log from a vmcore file
> > + * after a crash
> > + */
> >  void log_buf_kexec_setup(void)
> >  {
> >  	VMCOREINFO_SYMBOL(log_buf);
> > -	VMCOREINFO_SYMBOL(log_end);
> > +	VMCOREINFO_SYMBOL(log_buf_len);
> > +	VMCOREINFO_SYMBOL(logged_chars)
> >  }
> >  #endif
> 
> Please do not remove VMCOREINFO_SYMBOL(log_end), because makedumpfile
> needs it for knowing the latest log offset in ring buffer of dmesg.
> I updated a makedumpfile patch for handling ring buffer, and it is
> possible to download the latest patch from the following site:
> 
> https://sourceforge.net/tracker2/download.php?group_id=178938&atid=887142&file_id=312113&aid=2521075
> 
Understood, new patch attached.

Add some comments and extra symbols on top of whats there for kernel/printk.c to
satisfy Erics requests, and support Ken'ichi's enhanced version of the
makedumpfile patch

Neil

Signed-off-by: Neil Horman <nhorman@tuxdriver.com>



 printk.c |   11 +++++++++++
 1 file changed, 11 insertions(+)


diff --git a/kernel/printk.c b/kernel/printk.c
index dd5cc7b..6c25eba 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -138,10 +138,21 @@ static int log_buf_len = __LOG_BUF_LEN;
 static unsigned logged_chars; /* Number of chars produced since last read+clear operation */
 
 #ifdef CONFIG_KEXEC
+/*
+ * This appends the listed symbols to /proc/vmcoreinfo
+ * /proc/vmcoreinfo is used by various utiilties, like
+ * crash and makedumpfile to obtain access to symbols that
+ * are otherwise very difficult to locate.  These symbols 
+ * are specifically used so that utilities 
+ * can access and extract the dmesg log from a vmcore file
+ * after a crash
+ */
 void log_buf_kexec_setup(void)
 {
 	VMCOREINFO_SYMBOL(log_buf);
 	VMCOREINFO_SYMBOL(log_end);
+	VMCOREINFO_SYMBOL(log_buf_len);
+	VMCOREINFO_SYMBOL(logged_chars)
 }
 #endif
 

Re: [PATCH]: add dmesg log symbols to /proc/vmcoreinfo lists

[Simon Horman]

On Thu, Feb 05, 2009 at 06:52:54AM -0500, Neil Horman wrote:
> On Thu, Feb 05, 2009 at 09:23:22AM +0900, Ken'ichi Ohmichi wrote:
> > 
> > Hi Neil,
> > 
> > Thank you for a kernel patch and a makedumpfile patch.
> > 
> > Neil Horman wrote:
> > >> That aside we aren't currently exporting log_buf_len, so I don't
> > >> think this code works actually works.
> > >>
> > >> Neil can you add a comment in kernel/printk.c of the algorithm
> > >> necessary for external tools to decode the ring buffer?
> > >>
> > >> We need the comment because people working on kernel/printk.c
> > >> need to know what is happening and without having to review lots
> > >> of user space code, and we need the comment to verify that we
> > >> are exporting the right things.
> > >>
> > > 
> > > Ok, as per Erics comment, I've written this.  It applies on top of whats already
> > > in your tree Andrew.  It adds some comments on the function in question so that
> > > anyone working on printk.c will know why we're exporting their symbols.  It also
> > > modifies slightly the symbols we are exporting so that we can handle dmesg
> > > buffers that are longer than the standard PAGE_SIZE configuration, and lets us
> > > detect and handle buffer wraps.
> > > 
> > > Thanks!
> > > 
> > > printk.c |   12 +++++++++++-
> > > 1 file changed, 11 insertions(+), 1 deletion(-)
> > > 
> > > Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> > > 
> > > diff --git a/kernel/printk.c b/kernel/printk.c
> > > index dd5cc7b..6a1163b 100644
> > > --- a/kernel/printk.c
> > > +++ b/kernel/printk.c
> > > @@ -138,10 +138,20 @@ static int log_buf_len = __LOG_BUF_LEN;
> > >  static unsigned logged_chars; /* Number of chars produced since last read+clear operation */
> > >  
> > >  #ifdef CONFIG_KEXEC
> > > +/*
> > > + * This appends the listed symbols to /proc/vmcoreinfo
> > > + * /proc/vmcoreinfo is used by various utiilties, like
> > > + * crash and makedumpfile to obtain access to symbols that
> > > + * are otherwise very difficult to locate.  These symbols 
> > > + * are specifically used so that utilities 
> > > + * can access and extract the dmesg log from a vmcore file
> > > + * after a crash
> > > + */
> > >  void log_buf_kexec_setup(void)
> > >  {
> > >  	VMCOREINFO_SYMBOL(log_buf);
> > > -	VMCOREINFO_SYMBOL(log_end);
> > > +	VMCOREINFO_SYMBOL(log_buf_len);
> > > +	VMCOREINFO_SYMBOL(logged_chars)
> > >  }
> > >  #endif
> > 
> > Please do not remove VMCOREINFO_SYMBOL(log_end), because makedumpfile
> > needs it for knowing the latest log offset in ring buffer of dmesg.
> > I updated a makedumpfile patch for handling ring buffer, and it is
> > possible to download the latest patch from the following site:
> > 
> > https://sourceforge.net/tracker2/download.php?group_id=178938&atid=887142&file_id=312113&aid=2521075
> > 
> Understood, new patch attached.
> 
> Add some comments and extra symbols on top of whats there for kernel/printk.c to
> satisfy Erics requests, and support Ken'ichi's enhanced version of the
> makedumpfile patch
> 
> Neil
> 
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> 
> 
> 
>  printk.c |   11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> 
> diff --git a/kernel/printk.c b/kernel/printk.c
> index dd5cc7b..6c25eba 100644
> --- a/kernel/printk.c
> +++ b/kernel/printk.c
> @@ -138,10 +138,21 @@ static int log_buf_len = __LOG_BUF_LEN;
>  static unsigned logged_chars; /* Number of chars produced since last read+clear operation */
>  
>  #ifdef CONFIG_KEXEC
> +/*
> + * This appends the listed symbols to /proc/vmcoreinfo
> + * /proc/vmcoreinfo is used by various utiilties, like

Utilities appears to have a typo.

> + * crash and makedumpfile to obtain access to symbols that
> + * are otherwise very difficult to locate.  These symbols 
> + * are specifically used so that utilities 
> + * can access and extract the dmesg log from a vmcore file
> + * after a crash
> + */
>  void log_buf_kexec_setup(void)
>  {
>  	VMCOREINFO_SYMBOL(log_buf);
>  	VMCOREINFO_SYMBOL(log_end);
> +	VMCOREINFO_SYMBOL(log_buf_len);
> +	VMCOREINFO_SYMBOL(logged_chars)
>  }
>  #endif

-- 
Simon Horman
  VA Linux Systems Japan K.K., Sydney, Australia Satellite Office
  H: www.vergenet.net/~horms/             W: www.valinux.co.jp/en