On Tuesday 18 December 2007 17:46:15 Srinivasa Ds wrote: > 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().
Hi Srinivasa! That's not my point. What you care about is that the text still be there. The fact that it's the __init section which is discarded is a detail; if some other text section were discarded you'd want that excluded too. Hence non_init_ was a bad name; persistent is a bad name because it usually means something else in operating systems... > > 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. Sorry, I meant symbol_put_addr(). > > 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. No, symbol_put_addr() will fail to decrement the module count, thinking it's part of the (now-discarded) init section. > > 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. Perhaps, but two new functions is v. ugly. I'll try to come up with something neater, and audit all the callers. Thanks, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/