[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <47676CB7.4060203@in.ibm.com>
Date: Tue, 18 Dec 2007 12:16:15 +0530
From: Srinivasa Ds <srinivasa@...ibm.com>
To: Rusty Russell <rusty@...tcorp.com.au>
CC: ananth@...ibm.com, Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org,
Masami Hiramatsu <mhiramat@...hat.com>,
Jim Keniston <jkenisto@...ibm.com>
Subject: Re: [RFC] [patch 1/2] add non_init_kernel_text_address
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists