All of lore.kernel.org
 help / color / mirror / Atom feed
From: Srinivasa Ds <srinivasa@in.ibm.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: ananth@in.ibm.com, Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org,
	Masami Hiramatsu <mhiramat@redhat.com>,
	Jim Keniston <jkenisto@us.ibm.com>
Subject: Re: [RFC] [patch 1/2] add non_init_kernel_text_address
Date: Tue, 18 Dec 2007 12:16:15 +0530	[thread overview]
Message-ID: <47676CB7.4060203@in.ibm.com> (raw)
In-Reply-To: <200712181557.35712.rusty@rustcorp.com.au>

Rusty Russell wrote:
> On Friday 14 December 2007 18:51:06 Ananth N Mavinakayanahalli wrote:
>> On Thu, Dec 13, 2007 at 11:09:16PM -0800, Andrew Morton wrote:
>>> regular_kernel_text_address()?  Dunno.
>> Sounds better :-)
> 
> The better answer was to invert it and use "discarded_kernel_text_address()",
> which is what you actually care about (rather than the details of whether it
> was init or not).

Requirement is to ensure the address is really a kernel_text address and doesn't
lie in __init section. Hence I used persistent_kernel_text_address().

> 
> However, you have, in fact, located a potential bug.  If someone were to
> kmalloc module text, then symbol_put() could fail.

I don't think so, symbol_put() makes use of lookup_symbol() within __start_ksymtab
and  stop_ksymtab. 

> 
> How's this?
> ---
> Don't report discarded init pages as kernel text.
> 
> In theory this could cause a bug in symbol_put() if an arch used for
> a module: we might think the symbol belongs to the core kernel.

Yes, usage of symbol_put_addr() cause the BUG() if it fails
to find the address in core kernel.
> 
> The downside is that this might make backtraces through (discarded)
> init functions harder to read on some archs.
> 

I think it is better to make use of new function than sacrificing 
__init function symbol information in backtrace.

Thanks
 Srinivasa DS

  reply	other threads:[~2007-12-18  6:46 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-14  6:55 [RFC] [patch 1/2] add non_init_kernel_text_address Srinivasa Ds
2007-12-14  6:57 ` [RFC] [patch 2/2] Refuse kprobe insertion on __init section code Srinivasa Ds
2007-12-14  7:09 ` [RFC] [patch 1/2] add non_init_kernel_text_address Andrew Morton
2007-12-14  7:51   ` Ananth N Mavinakayanahalli
2007-12-18  4:57     ` Rusty Russell
2007-12-18  6:46       ` Srinivasa Ds [this message]
2007-12-18  7:23         ` Rusty Russell
2007-12-19  5:11           ` Rusty Russell
2008-01-01  6:34             ` Srinivasa Ds
2007-12-14  9:30   ` Srinivasa Ds
2007-12-14 10:17     ` Srinivasa Ds
2007-12-14 12:46       ` Johannes Weiner
2007-12-17 10:15         ` Srinivasa Ds
2007-12-17 10:20           ` [RFC] [patch 2/2] Refuse kprobe insertion on __init section code Srinivasa Ds
2007-12-14  9:34   ` Srinivasa Ds

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=47676CB7.4060203@in.ibm.com \
    --to=srinivasa@in.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=ananth@in.ibm.com \
    --cc=jkenisto@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhiramat@redhat.com \
    --cc=rusty@rustcorp.com.au \
    /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.