From: John Hodrien (johnh_at_comp.leeds.ac.uk)
Date: Thu Aug 30 2007 - 00:35:10 PDT
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`
c107b4e2 t __unregister_chrdev_region
c107b53d T unregister_chrdev
c107b567 T unregister_chrdev_region
c107b5a4 t __register_chrdev_region
c107b720 T register_chrdev
c107b947 T register_chrdev_region
c10e1bbf T unregister_blkdev
c10e20b2 T register_blkdev
c12cf680 r __ksymtab_unregister_chrdev
c12cf688 r __ksymtab_register_chrdev
c12cf6b8 r __ksymtab_unregister_chrdev_region
c12cf6c0 r __ksymtab_register_chrdev_region
c12d0608 r __ksymtab_unregister_blkdev
c12d0610 r __ksymtab_register_blkdev
c12d5354 r __kcrctab_unregister_chrdev
c12d5358 r __kcrctab_register_chrdev
c12d5370 r __kcrctab_unregister_chrdev_region
c12d5374 r __kcrctab_register_chrdev_region
c12d5b18 r __kcrctab_unregister_blkdev
c12d5b1c r __kcrctab_register_blkdev
c12db1d9 r __kstrtab_unregister_chrdev
c12db1eb r __kstrtab_register_chrdev
c12db236 r __kstrtab_unregister_chrdev_region
c12db24f r __kstrtab_register_chrdev_region
c12dda51 r __kstrtab_unregister_blkdev
c12dda63 r __kstrtab_register_blkdev
>> $ grep -e register_chrdev -e register_blkdev /proc/kallsyms
c047b4e2 t __unregister_chrdev_region
c047b53d T unregister_chrdev
c047b567 T unregister_chrdev_region
c047b5a4 t __register_chrdev_region
c047b720 T register_chrdev
c047b947 T register_chrdev_region
c04e1bbf T unregister_blkdev
c04e20b2 T register_blkdev
c06cf680 r __ksymtab_unregister_chrdev
c06cf688 r __ksymtab_register_chrdev
c06cf6b8 r __ksymtab_unregister_chrdev_region
c06cf6c0 r __ksymtab_register_chrdev_region
c06d0608 r __ksymtab_unregister_blkdev
c06d0610 r __ksymtab_register_blkdev
c06d5354 r __kcrctab_unregister_chrdev
c06d5358 r __kcrctab_register_chrdev
c06d5370 r __kcrctab_unregister_chrdev_region
c06d5374 r __kcrctab_register_chrdev_region
c06d5b18 r __kcrctab_unregister_blkdev
c06d5b1c r __kcrctab_register_blkdev
c06db1d9 r __kstrtab_unregister_chrdev
c06db1eb r __kstrtab_register_chrdev
c06db236 r __kstrtab_unregister_chrdev_region
c06db24f r __kstrtab_register_chrdev_region
c06dda51 r __kstrtab_unregister_blkdev
c06dda63 r __kstrtab_register_blkdev
c047b53d u unregister_chrdev [drm]
c047b720 u register_chrdev [drm]
c04e1bbf u unregister_blkdev [dm_mod]
c04e20b2 u register_blkdev [dm_mod]
c047b53d u unregister_chrdev [snd]
c047b720 u register_chrdev [snd]
c047b53d u unregister_chrdev [soundcore]
c047b720 u register_chrdev [soundcore]
c04e1bbf u unregister_blkdev [floppy]
c04e20b2 u register_blkdev [floppy]
c04e1bbf u unregister_blkdev [sr_mod]
c04e20b2 u register_blkdev [sr_mod]
c047b567 u unregister_chrdev_region [sg]
c047b947 u register_chrdev_region [sg]
c04e1bbf u unregister_blkdev [sd_mod]
c04e20b2 u register_blkdev [sd_mod]
>> 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
--
"One always tends to overpraise a long book, because one has got through it."
-- Edward Morgan Forster