From: Paul H. Hargrove (PHHargrove_at_lbl_dot_gov)
Date: Thu Aug 30 2007 - 04:39:40 PDT
John Hodrien wrote:
> On Wed, 29 Aug 2007, Paul H. Hargrove wrote:
>
>>> To access certain kernel symbols that are not exported to modules,
>>> BLCR's configure process locates the symbols in the System.map and
>>> encodes the addresses in the BLCR kernel modules. Such a practice is
>>> potentially error prone and could be dangerous if we tried to execute
>>> code at arbitrary addresses in the kernel. For that reason, we
>>> extract from System.map some addresses that can be compared against
>>> exported symbols and/or entries in the syscall table, and these are
>>> checked at module-load time. The error message you see means that
>>> checks comparing addresses in System.map against 2 exported symbols
>>> have failed. This normally means that wrong System.map file was used
>>> to build BLCR.
>
> Yep, I'd followed it this far.
>
>>> Based on a previously reported issue, I suspect your problem may be
>>> related to having a "relocatable" kernel. If you would, please,
>>> provide the output of the following three commands:
>>> $ grep RELOCATE /boot/config-`uname -r`
>> The line above should say RELOCATABLE rather than RELOCATE
>
> Bingo. CONFIG_RELOCATABLE=y
>
> I had a feeling it'd be some kernel feature I was missing. Thanks.
>
>>> $ grep -e register_chrdev -e register_blkdev /boot/System.map-`uname -r`
[snip]
> c107b720 T register_chrdev
[snip]
>>> $ grep -e register_chrdev -e register_blkdev /proc/kallsyms
[snip]
> c047b720 T register_chrdev
[snip]
>>> Based on the output of those commands, I should be able to confirm if
>>> the problem is a relocatable kernel, and hopefully formulate a fix.
>
> Thanks. So far all I've tried was building against a copy of
> /proc/kallsyms
> rather than against a System.map. This seemed to work fine for the
> latest F7
> kernel (2.6.22.4-65.fc7) but not for the previous one (2.6.22.1-41.fc7)
>
> jh
>
OK, it does appear the kernel has been relocated and this is leading to
the rejection at module load time.
I had already added code (only barely tested) to perform the relocation
of our symbols captured from System.map, but did not fix the validation
step. Since relocations need to obey the compiled-in PHYSICAL_ALIGN
restriction, it should be easy to validate that the symbols differ from
System.map by only a legal offset.
John,
Please try building from a BLCR source tarball with the attached
patch applied (and not using kallsyms) and let me know if it works.
Thanks,
-Paul
--
Paul H. Hargrove PHHargrove_at_lbl_dot_gov
Future Technologies Group
HPC Research Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
Index: cr_module/cr_module.c
===================================================================
RCS file: /var/local/cvs/lbnl_cr/cr_module/cr_module.c,v
retrieving revision 1.28
diff -u -r1.28 cr_module.c
--- cr_module/cr_module.c 24 Nov 2005 02:41:27 -0000 1.28
+++ cr_module/cr_module.c 30 Aug 2007 11:31:28 -0000
@@ -60,11 +60,20 @@
#endif
CR_INFO("blcr: Supports BLCR kernel interface version %s.", CR_MODULE_VERSION);
CR_INFO("blcr: %s", PACKAGE_BUGREPORT);
+
/* Check current kernel against System.map used af configure time */
- if ((CR_EXPORTED_KCODE_register_chrdev != (unsigned long)®ister_chrdev) ||
- (CR_EXPORTED_KCODE_register_blkdev != (unsigned long)®ister_blkdev)) {
+ {
+ unsigned long offset1 = CR_EXPORTED_KCODE_register_chrdev - (unsigned long)®ister_chrdev;
+ unsigned long offset2 = CR_EXPORTED_KCODE_register_blkdev - (unsigned long)®ister_blkdev;
+#if defined(CONFIG_RELOCATABLE) && defined(PHYSICAL_ALIGN)
+ unsigned long unaligned = offset1 && (PHYSICAL_ALIGN - 1);
+#else
+ unsigned long unaligned = offset1 != 0;
+#endif
+ if (unaligned || (offset1 != offset2)) {
CR_ERR("Running kernel does not match the System.map used to build blcr.o");
return -EINVAL;
+ }
}
#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,0))