linux-kernel - Re: [PATCH] reduce the time of finding symbols for module

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <58DA41EE.90607@huawei.com>
Date:   Tue, 28 Mar 2017 18:58:54 +0800
From:   zhouchengming <zhouchengming1@...wei.com>
To:     Miroslav Benes <mbenes@...e.cz>
CC:     <live-patching@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <jpoimboe@...hat.com>, <jeyu@...hat.com>, <jikos@...nel.org>,
        <pmladek@...e.com>, <huawei.libin@...wei.com>
Subject: Re: [PATCH] reduce the time of finding symbols for module

On 2017/3/28 17:00, Miroslav Benes wrote:
>
> Hi,
>
> On Tue, 28 Mar 2017, Zhou Chengming wrote:
>
>> It's reported that the time of insmoding a klp.ko for one of our
>> out-tree modules is too long.
>>
>> ~ time sudo insmod klp.ko
>> real	0m23.799s
>> user	0m0.036s
>> sys	0m21.256s
>
> Is this stable through several (>=10) runs? 23 seconds are really
> suspicious. Yes, there is a linear search through all the kallsyms in
> kallsyms_on_each_symbol(), but there are something like 70k symbols on my
> machine (that is, way less than 1M). 23 seconds are somewhat unexpected.
>

Yes, it's stable through several runs.

I think the big reason is that our out-tree module used a lot of static local
variables. We can see '.rela.kpatch.dynrelas' contains many entries, so it will
waste a lot of time if we use kallsyms_on_each_symbol() to find these symbols of module.

Relocation section '.rela.kpatch.funcs' at offset 0x382e0 contains 3 entries:
   Offset          Info           Type           Sym. Value    Sym. Name + Addend
000000000000  003300000101 R_AARCH64_ABS64   0000000000000000 value_show + 0
000000000020  000b00000101 R_AARCH64_ABS64   0000000000000000 .kpatch.strings + 8
000000000028  000b00000101 R_AARCH64_ABS64   0000000000000000 .kpatch.strings + 0

Relocation section '.rela.kpatch.dynrelas' at offset 0x38328 contains 2562 entries:
   Offset          Info           Type           Sym. Value    Sym. Name + Addend
000000000000  003300000101 R_AARCH64_ABS64   0000000000000000 value_show + 14
000000000018  000b00000101 R_AARCH64_ABS64   0000000000000000 .kpatch.strings + 13
000000000020  000b00000101 R_AARCH64_ABS64   0000000000000000 .kpatch.strings + 0
000000000040  003300000101 R_AARCH64_ABS64   0000000000000000 value_show + 20
000000000058  000b00000101 R_AARCH64_ABS64   0000000000000000 .kpatch.strings + 13
000000000060  000b00000101 R_AARCH64_ABS64   0000000000000000 .kpatch.strings + 0

> If it is a problem, can we fix kallsyms_on_each_symbol() and replace the
> linear search with something better? All users would benefit...
>

Yes, it's better if we can improve the linear search, but I can't think of that...

Thanks.

> Thanks,
> Miroslav
>
> .
>