public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Hugh Dickins <hugh@veritas.com>
Cc: penberg@cs.helsinki.fi, rjw@sisk.pl, miles.lane@gmail.com,
	linux-kernel@vger.kernel.org, cl@linux-foundation.org,
	mingo@elte.hu, htejun@gmail.com, vegard.nossum@gmail.com,
	rostedt@goodmis.org, arjan@infradead.org,
	Rusty Russell <rusty@rustcorp.com.au>
Subject: Re: 2.6.28-rc6-git1 -- BUG: unable to handle kernel paging request at ffff8800be8b0019
Date: Mon, 1 Dec 2008 12:51:03 -0800	[thread overview]
Message-ID: <20081201125103.db4c026f.akpm@linux-foundation.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0811271643250.9618@blonde.site>

On Thu, 27 Nov 2008 17:34:27 +0000 (GMT)
Hugh Dickins <hugh@veritas.com> wrote:

> [PATCH] KSYM_SYMBOL_LEN fixes
> 
> Miles Lane tailing /sys files hit a BUG which Pekka Enberg has tracked to
> my 966c8c12dc9e77f931e2281ba25d2f0244b06949 sprint_symbol(): use less stack
> exposing a bug in slub's list_locations() - kallsyms_lookup() writes a 0
> to namebuf[KSYM_NAME_LEN-1], but that was beyond the end of page provided.
> 
> The 100 slop which list_locations() allows at end of page looks roughly
> enough for all the other stuff it might print after the symbol before
> it checks again: break out KSYM_SYMBOL_LEN earlier than before.
> 
> Latencytop and ftrace and are using KSYM_NAME_LEN buffers where they need
> KSYM_SYMBOL_LEN buffers, and vmallocinfo a 2*KSYM_NAME_LEN buffer where
> it wants a KSYM_SYMBOL_LEN buffer: fix those before anyone copies them.
> 
> Signed-off-by: Hugh Dickins <hugh@veritas.com>
> ---
> 
>  fs/proc/base.c         |    2 +-
>  include/linux/ftrace.h |    2 +-
>  kernel/latencytop.c    |    2 +-
>  mm/slub.c              |    2 +-
>  mm/vmalloc.c           |    2 +-
>  5 files changed, 5 insertions(+), 5 deletions(-)
> 
> --- 2.6.28-rc6/fs/proc/base.c	2008-10-24 09:28:19.000000000 +0100
> +++ linux/fs/proc/base.c	2008-11-27 16:39:26.000000000 +0000
> @@ -371,7 +371,7 @@ static int lstats_show_proc(struct seq_f
>  				task->latency_record[i].time,
>  				task->latency_record[i].max);
>  			for (q = 0; q < LT_BACKTRACEDEPTH; q++) {
> -				char sym[KSYM_NAME_LEN];
> +				char sym[KSYM_SYMBOL_LEN];
>  				char *c;
>  				if (!task->latency_record[i].backtrace[q])
>  					break;
> --- 2.6.28-rc6/include/linux/ftrace.h	2008-11-02 23:17:56.000000000 +0000
> +++ linux/include/linux/ftrace.h	2008-11-27 16:39:26.000000000 +0000
> @@ -231,7 +231,7 @@ ftrace_init_module(unsigned long *start,
>  
>  struct boot_trace {
>  	pid_t			caller;
> -	char			func[KSYM_NAME_LEN];
> +	char			func[KSYM_SYMBOL_LEN];
>  	int			result;
>  	unsigned long long	duration;		/* usecs */
>  	ktime_t			calltime;

The ftrace.h change causes this:

In file included from arch/x86/kernel/machine_kexec_64.c:14:
include/linux/ftrace.h:234: error: 'MODULE_NAME_LEN' undeclared here (not in a function)

The fault really lies with include/linux/kallsyms.h, I think:

#define KSYM_SYMBOL_LEN (sizeof("%s+%#lx/%#lx [%s]") + (KSYM_NAME_LEN - 1) + \
                         2*(BITS_PER_LONG*3/10) + (MODULE_NAME_LEN - 1) + 1)

but it doesn't include module.h, so it requires that users of this
header perform the include.

But I'm a bit reluctant to include module.h from kallsyms.h because
kallsyms.h is a simple low-level thing:

#include <linux/errno.h>
#include <linux/kernel.h>
#include <linux/stddef.h>

and it wouldn't surprise me if module.h was including kallsyms.h by
some means.

So for now I'll try including module.h from ftrace.c.  It would be nice
to fix the kallsyms.h dependency..


  parent reply	other threads:[~2008-12-01 20:52 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-25 16:50 2.6.28-rc6-git1 -- BUG: unable to handle kernel paging request at ffff8800be8b0019 Miles Lane
2008-11-26 23:26 ` Rafael J. Wysocki
2008-11-27 13:37   ` Pekka Enberg
2008-11-27 13:50     ` Vegard Nossum
2008-11-27 13:54     ` Hugh Dickins
2008-11-27 14:13       ` Pekka Enberg
2008-11-27 17:34         ` Hugh Dickins
2008-11-27 21:23           ` Pekka Enberg
2008-11-27 21:56             ` Hugh Dickins
2008-11-27 22:51               ` Christoph Lameter
2008-11-28  7:57                 ` Pekka Enberg
2008-11-27 23:27               ` Steven Rostedt
2008-11-27 23:31           ` Steven Rostedt
2008-11-28  0:16             ` Frederic Weisbecker
2008-11-29  6:40             ` Andrew Morton
2008-11-28  7:56           ` Pekka Enberg
2008-12-01 20:51           ` Andrew Morton [this message]
2008-12-01 22:47             ` Hugh Dickins
2008-12-02  0:57             ` Rusty Russell
2008-11-27 16:14   ` Miles Lane

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081201125103.db4c026f.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=arjan@infradead.org \
    --cc=cl@linux-foundation.org \
    --cc=htejun@gmail.com \
    --cc=hugh@veritas.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miles.lane@gmail.com \
    --cc=mingo@elte.hu \
    --cc=penberg@cs.helsinki.fi \
    --cc=rjw@sisk.pl \
    --cc=rostedt@goodmis.org \
    --cc=rusty@rustcorp.com.au \
    --cc=vegard.nossum@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox