Dne 30.9.2016 v 01:26 Stephen Rothwell napsal(a):
> Hi all,
>
> On Tue, 20 Sep 2016 10:55:32 +0800 kernel test robot <[email protected]> wrote:
>>
>> FYI, we noticed the following commit:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
>> commit 784d5699eddc55878627da20d3fe0c8542e2f1a2 ("x86: move exports to actual definitions")
>>
>> in testcase: boot
>>
>> on test machine: qemu-system-x86_64 -enable-kvm -cpu host -smp 2 -m 4G
>>
>> caused below changes:
>>
>> [ 4.386609] ip_tables: no symbol version for _copy_from_user
>> [ 4.387902] ip_tables: Unknown symbol _copy_from_user (err -22)
>> [ 4.389219] ip_tables: no symbol version for __put_user_2
>> [ 4.390473] ip_tables: Unknown symbol __put_user_2 (err -22)
>> [ 4.391760] ip_tables: no symbol version for __sw_hweight32
>> [ 4.393031] ip_tables: Unknown symbol __sw_hweight32 (err -22)
>> [ 4.394332] ip_tables: no symbol version for memcpy
>> [ 4.395508] ip_tables: Unknown symbol memcpy (err -22)
>> [ 4.396729] ip_tables: no symbol version for __fentry__
>> [ 4.397937] ip_tables: Unknown symbol __fentry__ (err -22)
>> [ 4.399234] ip_tables: no symbol version for _copy_to_user
>> [ 4.400488] ip_tables: Unknown symbol _copy_to_user (err -22)
>> [ 4.405835] systemd[1]: Failed to insert module 'ip_tables': Invalid argument
>>
>>
>>
>> Thanks,
>> Xiaolong
>
> Do we have any resolution of this?
With which .config is it happening? In my testing, the undefined CRCs
show up as 0x00000000 in Module.symvers and they are also 0 in the
___kcrctab* sections in vmlinux. So the loader matches the requested and
provided symbol's CRC of 0 and is happy. But I guess I'm missing something.
Thanks,
Michal
Dne 11.10.2016 v 15:10 Michal Marek napsal(a):
> Dne 30.9.2016 v 01:26 Stephen Rothwell napsal(a):
>> Hi all,
>>
>> On Tue, 20 Sep 2016 10:55:32 +0800 kernel test robot <[email protected]> wrote:
>>>
>>> FYI, we noticed the following commit:
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
>>> commit 784d5699eddc55878627da20d3fe0c8542e2f1a2 ("x86: move exports to actual definitions")
>>>
>>> in testcase: boot
>>>
>>> on test machine: qemu-system-x86_64 -enable-kvm -cpu host -smp 2 -m 4G
>>>
>>> caused below changes:
>>>
>>> [ 4.386609] ip_tables: no symbol version for _copy_from_user
>>> [ 4.387902] ip_tables: Unknown symbol _copy_from_user (err -22)
>>> [ 4.389219] ip_tables: no symbol version for __put_user_2
>>> [ 4.390473] ip_tables: Unknown symbol __put_user_2 (err -22)
>>> [ 4.391760] ip_tables: no symbol version for __sw_hweight32
>>> [ 4.393031] ip_tables: Unknown symbol __sw_hweight32 (err -22)
>>> [ 4.394332] ip_tables: no symbol version for memcpy
>>> [ 4.395508] ip_tables: Unknown symbol memcpy (err -22)
>>> [ 4.396729] ip_tables: no symbol version for __fentry__
>>> [ 4.397937] ip_tables: Unknown symbol __fentry__ (err -22)
>>> [ 4.399234] ip_tables: no symbol version for _copy_to_user
>>> [ 4.400488] ip_tables: Unknown symbol _copy_to_user (err -22)
>>> [ 4.405835] systemd[1]: Failed to insert module 'ip_tables': Invalid argument
>>>
>>>
>>>
>>> Thanks,
>>> Xiaolong
>>
>> Do we have any resolution of this?
>
> With which .config is it happening?
Or maybe with which toolchain is the kernel built.
Thanks,
Michal
Hi Michal,
Sorry for late reply. My toolchain in arch linux gcc version 6.2.1
20160830. I used defconfig (x86_64), with CONFIG_MODVERSIONS=y.
I'm understanding better what's happening here. Running:
nm arch/x86/lib/clear_page_64.o
gives,
0000000000000000 T clear_page
0000000000000050 T clear_page_c_e
0000000000000010 T clear_page_orig
w __crc_clear_page
0000000000000000 r __kcrctab_clear_page
0000000000000000 r __kstrtab_clear_page
0000000000000000 R __ksymtab_clear_page
but running
nm vmlinux|grep __crc_clear_page
gives,
0000000051fac2d3 A __crc_clear_page_dirty_for_io
So the weak symbol "__crc_clear_page" is not copied in vmlinux during
linking. modpost uses __crc_* symbols to extract crc. Not founding
those crc, it doesn't include symbols in mod.c modversion_info struct.
It seems to be a linker bug. I also tested linking:
<main.c>
int main() {
return 0;
}
and
<test.S>
.section test,"a"
__kcrctab_test:
.quad __test
.weak __test
Linking main.o and test.o,
* weak symbol "__test" appears in a.out with gcc 5.4.0
* weak symbol "__test" *does not* appear in a.out with gcc 6.2.1
I'll try to find if there is a related bug report in gcc.
Thanks,
Mathieu
On 10/11, Michal Marek wrote:
>Dne 11.10.2016 v 15:10 Michal Marek napsal(a):
>> Dne 30.9.2016 v 01:26 Stephen Rothwell napsal(a):
>>> Hi all,
>>>
>>> On Tue, 20 Sep 2016 10:55:32 +0800 kernel test robot <[email protected]> wrote:
>>>>
>>>> FYI, we noticed the following commit:
>>>>
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
>>>> commit 784d5699eddc55878627da20d3fe0c8542e2f1a2 ("x86: move exports to actual definitions")
>>>>
>>>> in testcase: boot
>>>>
>>>> on test machine: qemu-system-x86_64 -enable-kvm -cpu host -smp 2 -m 4G
>>>>
>>>> caused below changes:
>>>>
>>>> [ 4.386609] ip_tables: no symbol version for _copy_from_user
>>>> [ 4.387902] ip_tables: Unknown symbol _copy_from_user (err -22)
>>>> [ 4.389219] ip_tables: no symbol version for __put_user_2
>>>> [ 4.390473] ip_tables: Unknown symbol __put_user_2 (err -22)
>>>> [ 4.391760] ip_tables: no symbol version for __sw_hweight32
>>>> [ 4.393031] ip_tables: Unknown symbol __sw_hweight32 (err -22)
>>>> [ 4.394332] ip_tables: no symbol version for memcpy
>>>> [ 4.395508] ip_tables: Unknown symbol memcpy (err -22)
>>>> [ 4.396729] ip_tables: no symbol version for __fentry__
>>>> [ 4.397937] ip_tables: Unknown symbol __fentry__ (err -22)
>>>> [ 4.399234] ip_tables: no symbol version for _copy_to_user
>>>> [ 4.400488] ip_tables: Unknown symbol _copy_to_user (err -22)
>>>> [ 4.405835] systemd[1]: Failed to insert module 'ip_tables': Invalid argument
>>>>
>>>>
>>>>
>>>> Thanks,
>>>> Xiaolong
>>>
>>> Do we have any resolution of this?
>>
>> With which .config is it happening?
>
>Or maybe with which toolchain is the kernel built.
Sorry for the late. The config is attached (you can also see it in
original report), and the kernel was built with gcc version 6.2.0 20160901 (Debian
6.2.0-3)
Thanks,
Xiaolong
>
>Thanks,
>Michal
>
>_______________________________________________
>LKP mailing list
>[email protected]
>https://lists.01.org/mailman/listinfo/lkp