All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paulo Marques <pmarques@grupopie.com>
To: Robert Peterson <rpeterso@redhat.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2.6.21-rc1] Extend print_symbol capability TRY #3
Date: Wed, 07 Mar 2007 14:38:24 +0000	[thread overview]
Message-ID: <45EECE60.4010808@grupopie.com> (raw)
In-Reply-To: <45EDCE67.3010902@redhat.com>

Robert Peterson wrote:
>[...]
> @@ -47,6 +52,11 @@ static inline const char *kallsyms_lookup(unsigned 
> long addr,
>     return NULL;
> }
> 
> +static inline void sprint_symbol(char *buffer, unsigned long addr)
> +{
> +    return;
> +}

I'm really sorry for not replying sooner (I've been really busy), but 
this function still doesn't seem right.

If someone does something like:

> void my_function(unsigned long addr)
> {
> 	char buffer[KSYM_SYMBOL_LEN];
> 
> 	sprint_symbol(buffer, addr);
> 	...
> 	// use buffer to print somewhere
> 	...
> }

which seems like a perfectly natural thing to do, it might just oops the 
kernel if CONFIG_KALLSYMS is not set, because the buffer will be left 
uninitialized.

That is why I suggested to change it to something like "*buffer = '\0'" 
instead.

The really nice solution IMHO, would be to remove the print_symbol and 
sprint_symbol functions from the the "#ifdef CONFIG_KALLSYMS" and just 
let them be available even in a not CONFIG_KALLSYMS kernel.

Since kallsyms_lookup is already #ifdef'ed to something sane, 
sprint_symbol will just print out the symbol address in that case, but 
it is better than not printing anything at all.

-- 
Paulo Marques - www.grupopie.com

"Very funny Scotty. Now beam up my clothes."

  reply	other threads:[~2007-03-07 14:38 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-06 20:26 [PATCH 2.6.21-rc1] Extend print_symbol capability TRY #3 Robert Peterson
2007-03-07 14:38 ` Paulo Marques [this message]
2007-03-07 15:50   ` Robert Peterson
2007-03-07 16:01     ` Paulo Marques

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=45EECE60.4010808@grupopie.com \
    --to=pmarques@grupopie.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rpeterso@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.