lkml.org 
[lkml]   [2013]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patches in this message
/
SubjectRe: [linux-next-20130903] module: broken module versions?
From
Date
Hello.

This issue is not yet fixed as of linux-next-20130903. Without fixing this
issue, we would get 3.12-rc1 which cannot load several modules.

> I noticed that symbols which cause "disagrees about version of symbol" messages
> have crc == 0.

I tried further debugging but not yet successful.

---------- debug patch start ----------
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1192,6 +1192,9 @@ static int check_version(Elf_Shdr *sechdrs,
if (strcmp(versions[i].name, symname) != 0)
continue;

+ printk("Found %s checksum %lX vs module %lX\n",
+ versions[i].name, maybe_relocated(*crc, crc_owner),
+ versions[i].crc);
if (versions[i].crc == maybe_relocated(*crc, crc_owner))
return 1;
pr_debug("Found checksum %lX vs module %lX\n",
---------- debug patch end ----------
On x86_64, it shows

Found sock_register checksum 0 vs module 0
Found ns_capable checksum 0 vs module 0

and loading of ipv6.ko succeeds.

On x86_32, it shows

Found sock_register checksum FF100000 vs module 0
Found ns_capable checksum FF100000 vs module 0
and loading of ipv6.ko fails.

Thus, I came to assume that crc == 0 is the expected value but for some reason
crc == 0xFF100000 is recorded into kcrctab tables.


---------- debug patch start ----------
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -320,6 +320,11 @@ bool each_symbol_section(bool (*fn)(const struct symsearch *arr,
#endif
};

+ static unsigned int i;
+ for (; i < __stop___ksymtab - __start___ksymtab; i++)
+ printk("%d crc(%s)=%lx\n", i, __start___ksymtab[i].name,
+ __start___kcrctab[i]);
+
if (each_symbol_in_section(arr, ARRAY_SIZE(arr), NULL, fn, data))
return true;

---------- debug patch end ----------
On x86_64, "grep =0" shows

236 crc(__symbol_put)=0
784 crc(current_fs_time)=0
810 crc(d_tmpfile)=0
955 crc(do_sync_read)=0
1093 crc(filp_close)=0
1107 crc(finish_open)=0
1183 crc(generic_getxattr)=0
1207 crc(generic_write_sync)=0
1237 crc(get_unmapped_area)=0
1335 crc(in_group_p)=0
1407 crc(inode_add_bytes)=0
1495 crc(iov_shorten)=0
1548 crc(iterate_fd)=0
1815 crc(mnt_set_expiry)=0
2038 crc(ns_capable)=0
2102 crc(path_is_under)=0
2405 crc(register_exec_domain)=0
2506 crc(schedule_timeout)=0
2911 crc(sock_register)=0
2922 crc(softirq_work_list)=0
2996 crc(sys_close)=0
3022 crc(task_nice)=0
3243 crc(vfs_fsync_range)=0
3270 crc(vm_brk)=0

On x86_32, "grep =ff100000" shows
244 crc(__symbol_put)=ff100000
784 crc(current_fs_time)=ff100000
810 crc(d_tmpfile)=ff100000
967 crc(do_sync_read)=ff100000
1108 crc(filp_close)=ff100000
1122 crc(finish_open)=ff100000
1198 crc(generic_getxattr)=ff100000
1222 crc(generic_write_sync)=ff100000
1253 crc(get_unmapped_area)=ff100000
1351 crc(in_group_p)=ff100000
1423 crc(inode_add_bytes)=ff100000
1510 crc(iov_shorten)=ff100000
1567 crc(iterate_fd)=ff100000
1840 crc(mnt_set_expiry)=ff100000
2061 crc(ns_capable)=ff100000
2126 crc(path_is_under)=ff100000
2432 crc(register_exec_domain)=ff100000
2535 crc(schedule_timeout)=ff100000
2940 crc(sock_register)=ff100000
2951 crc(softirq_work_list)=ff100000
3013 crc(sys_close)=ff100000
3039 crc(task_nice)=ff100000
3261 crc(vfs_fsync_range)=ff100000
3288 crc(vm_brk)=ff100000
Module.symvers says that these symbols have crc == 0x00000000 and
kcrctab on x86_64 says that these symbols have crc == 0x00000000 but
kcrctab on x86_32 says that these symbols have crc == 0xff100000.
Prior to commit 5c019369 "syscalls.h: use gcc alias instead of assembler
aliases for syscalls", only crc(softirq_work_list)=ff100000 line was shown.


I don't know where 0xff100000 comes from, but this value is kconfig dependent
and this value might be by error introduced.
I also tried older kernels. As far as I tested (I might be wrong as this value
is kconfig dependent), it seems that 3.9 and later kernels show
crc(softirq_work_list)=ff100000 line while 3.8 and earlier kernels show
crc(softirq_work_list)=0 line. I'll try to bisect between 3.8 and 3.9 if this
change is by error introduced.

\
 
 \ /
  Last update: 2013-09-03 14:01    [W:0.090 / U:0.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site