From: Robin Getz <rgetz@blackfin.uclinux.org>
Organization: Blackfin uClinux org
To: Rusty Russell <rusty@rustcorp.com.au>
Subject: managing kallsyms_addresses
Date: Thu, 31 Jan 2008 11:48:18 -0500
User-Agent: KMail/1.9.5
Cc: linux-kernel@vger.kernel.org
MIME-Version: 1.0
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200801311148.18859.rgetz@blackfin.uclinux.org>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1296
Lines: 29

When the kernel needs to find out what symbol is at a specific address, it 
uses kallsyms_lookup() This seems to work pretty well - almost.

The problem is today, we don't to remove the symbols from the init section 
when the init section is freed. There is invalid data in kallsyms_addresses.

The problem I have been experiencing - If you have a module get loaded into a 
location which was init, then kallsyms_lookup()  can return init labels, 
rather than the module labels. (since it looks up kernel labels before module 
labels).

What happens is if there is a OOPS in the module, the labels from the OOPS can 
point to init code (which doesn't exist), which confuses the heck out of 
users and developers... 

There would be two solutions:
 - when freeing the init section, remove all the init labels from the 
kallsyms_addresses, and resort/pack it.
 - if the init section is unloaded, have is_kernel_inittext always return 0.

I assume that similar things need to be handled for module init too, but I 
have not run into that yet.

Thoughts?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/