* [PATCH] reduce the time of finding symbols for module
@ 2017-03-28 2:02 Zhou Chengming
2017-03-28 9:00 ` Miroslav Benes
0 siblings, 1 reply; 12+ messages in thread
From: Zhou Chengming @ 2017-03-28 2:02 UTC (permalink / raw)
To: live-patching, linux-kernel
Cc: jpoimboe, jeyu, jikos, mbenes, pmladek, huawei.libin, zhouchengming1
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
Then we found the reason: klp_find_object_symbol() uses the interface
kallsyms_on_each_symbol() even for finding module symbols, so will waste
a lot of time. This patch changes it to use module_kallsyms_on_each_symbol()
for modules symbols.
After we apply this patch, the sys time reduced dramatically.
~ time sudo insmod klp.ko
real 0m1.007s
user 0m0.032s
sys 0m0.924s
Signed-off-by: Zhou Chengming <zhouchengming1@huawei.com>
---
kernel/livepatch/core.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
index af46438..b4b8bb0 100644
--- a/kernel/livepatch/core.c
+++ b/kernel/livepatch/core.c
@@ -182,7 +182,10 @@ static int klp_find_object_symbol(const char *objname, const char *name,
};
mutex_lock(&module_mutex);
- kallsyms_on_each_symbol(klp_find_callback, &args);
+ if (objname)
+ module_kallsyms_on_each_symbol(klp_find_callback, &args);
+ else
+ kallsyms_on_each_symbol(klp_find_callback, &args);
mutex_unlock(&module_mutex);
/*
--
1.8.3.1
^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH] reduce the time of finding symbols for module
2017-03-28 2:02 [PATCH] reduce the time of finding symbols for module Zhou Chengming
@ 2017-03-28 9:00 ` Miroslav Benes
2017-03-28 10:58 ` zhouchengming
0 siblings, 1 reply; 12+ messages in thread
From: Miroslav Benes @ 2017-03-28 9:00 UTC (permalink / raw)
To: Zhou Chengming
Cc: live-patching, linux-kernel, jpoimboe, jeyu, jikos, pmladek,
huawei.libin
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.
If it is a problem, can we fix kallsyms_on_each_symbol() and replace the
linear search with something better? All users would benefit...
Thanks,
Miroslav
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] reduce the time of finding symbols for module
2017-03-28 9:00 ` Miroslav Benes
@ 2017-03-28 10:58 ` zhouchengming
2017-03-28 11:16 ` Miroslav Benes
0 siblings, 1 reply; 12+ messages in thread
From: zhouchengming @ 2017-03-28 10:58 UTC (permalink / raw)
To: Miroslav Benes
Cc: live-patching, linux-kernel, jpoimboe, jeyu, jikos, pmladek,
huawei.libin
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
>
> .
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] reduce the time of finding symbols for module
2017-03-28 10:58 ` zhouchengming
@ 2017-03-28 11:16 ` Miroslav Benes
2017-03-28 12:50 ` zhouchengming
2017-03-29 0:03 ` Jessica Yu
0 siblings, 2 replies; 12+ messages in thread
From: Miroslav Benes @ 2017-03-28 11:16 UTC (permalink / raw)
To: zhouchengming
Cc: live-patching, linux-kernel, jpoimboe, jeyu, jikos, pmladek,
huawei.libin
On Tue, 28 Mar 2017, zhouchengming wrote:
> 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.
Ok, it means that you have a lot of relocation records which reference
your out-of-tree module. Then for each such entry klp_resolve_symbol()
is called and then klp_find_object_symbol() to actually resolve it. So if
you have 20k entries, you walk through vmlinux kallsyms table 20k times.
It is unneeded and that is why your fix works.
But if there were 20k modules loaded, the problem would still be there.
I think it would be really nice to fix kallsyms :). Replace ordinary array
and the linear search with a hash table.
> 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
Hm, we do not have aarch64 support in upstream (yet). There is even no
dynamic ftrace with regs yet (if I am not mistaken).
> 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...
I don't understand. Fixing kallsyms is of course much more work but
everyone would benefit from that.
If there is an agreement, we could accept your solution as temporary. In
such case, please prefix the subject with 'livepatch: ' and use capital
letter in 'Reduce'. Please also improve the changelog and describe where
the problem really is.
Thanks,
Miroslav
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] reduce the time of finding symbols for module
2017-03-28 11:16 ` Miroslav Benes
@ 2017-03-28 12:50 ` zhouchengming
2017-03-29 0:03 ` Jessica Yu
1 sibling, 0 replies; 12+ messages in thread
From: zhouchengming @ 2017-03-28 12:50 UTC (permalink / raw)
To: Miroslav Benes
Cc: live-patching, linux-kernel, jpoimboe, jeyu, jikos, pmladek,
huawei.libin
On 2017/3/28 19:16, Miroslav Benes wrote:
> On Tue, 28 Mar 2017, zhouchengming wrote:
>
>> 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.
>
> Ok, it means that you have a lot of relocation records which reference
> your out-of-tree module. Then for each such entry klp_resolve_symbol()
> is called and then klp_find_object_symbol() to actually resolve it. So if
> you have 20k entries, you walk through vmlinux kallsyms table 20k times.
> It is unneeded and that is why your fix works.
>
> But if there were 20k modules loaded, the problem would still be there.
>
Yes, vmlinux kallsyms table is too big, but modules loaded are always few.
> I think it would be really nice to fix kallsyms :). Replace ordinary array
> and the linear search with a hash table.
>
>> 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
>
> Hm, we do not have aarch64 support in upstream (yet). There is even no
> dynamic ftrace with regs yet (if I am not mistaken).
>
>> 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...
>
> I don't understand. Fixing kallsyms is of course much more work but
> everyone would benefit from that.
>
> If there is an agreement, we could accept your solution as temporary. In
> such case, please prefix the subject with 'livepatch: ' and use capital
> letter in 'Reduce'. Please also improve the changelog and describe where
> the problem really is.
>
Ok, if there are no oppositions, I will send a patch-v2 with improved changelog.
This is really a temporary solution, and others can go on to fix the kallsyms
if needed later.
Thanks.
> Thanks,
> Miroslav
>
> .
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] reduce the time of finding symbols for module
2017-03-28 11:16 ` Miroslav Benes
2017-03-28 12:50 ` zhouchengming
@ 2017-03-29 0:03 ` Jessica Yu
2017-03-29 1:50 ` Li Bin
1 sibling, 1 reply; 12+ messages in thread
From: Jessica Yu @ 2017-03-29 0:03 UTC (permalink / raw)
To: Miroslav Benes
Cc: zhouchengming, live-patching, linux-kernel, jpoimboe, jikos,
pmladek, huawei.libin
+++ Miroslav Benes [28/03/17 13:16 +0200]:
>On Tue, 28 Mar 2017, zhouchengming wrote:
>
>> 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.
>
>Ok, it means that you have a lot of relocation records which reference
>your out-of-tree module. Then for each such entry klp_resolve_symbol()
>is called and then klp_find_object_symbol() to actually resolve it. So if
>you have 20k entries, you walk through vmlinux kallsyms table 20k times.
>It is unneeded and that is why your fix works.
>
>But if there were 20k modules loaded, the problem would still be there.
>
>I think it would be really nice to fix kallsyms :). Replace ordinary array
>and the linear search with a hash table.
>
>> 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
>
>Hm, we do not have aarch64 support in upstream (yet). There is even no
>dynamic ftrace with regs yet (if I am not mistaken).
I'm curious, how was this tested? Since there is no dynamic ftrace
with regs and no livepatch stubs (klp_arch_set_pc, etc) implemented
yet for aarch64. Also, livepatch has switched from klp_relocs/dynrelas
to .klp.rela. sections since 4.7, so I'm curious how your patch module
has a .kpatch.dynrelas section working with livepatch.
Unrelated to this patch, if there is a working aarch64 livepatch port (and
kpatch build tool, it seems) floating out there, it would be
wonderful to push that upstream :-)
Jessica
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] reduce the time of finding symbols for module
2017-03-29 0:03 ` Jessica Yu
@ 2017-03-29 1:50 ` Li Bin
2017-03-29 19:09 ` Jessica Yu
2017-10-13 12:54 ` Ruslan Bilovol
0 siblings, 2 replies; 12+ messages in thread
From: Li Bin @ 2017-03-29 1:50 UTC (permalink / raw)
To: Jessica Yu, Miroslav Benes
Cc: zhouchengming, live-patching, linux-kernel, jpoimboe, jikos,
pmladek, Zefan Li, Hanjun Guo, duwe, huawei.libin
Hi,
on 2017/3/29 8:03, Jessica Yu wrote:
> +++ Miroslav Benes [28/03/17 13:16 +0200]:
>> On Tue, 28 Mar 2017, zhouchengming wrote:
>>
>>> 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.
>>
>> Ok, it means that you have a lot of relocation records which reference
>> your out-of-tree module. Then for each such entry klp_resolve_symbol()
>> is called and then klp_find_object_symbol() to actually resolve it. So if
>> you have 20k entries, you walk through vmlinux kallsyms table 20k times.
>> It is unneeded and that is why your fix works.
>>
>> But if there were 20k modules loaded, the problem would still be there.
>>
>> I think it would be really nice to fix kallsyms :). Replace ordinary array
>> and the linear search with a hash table.
>>
>>> 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
>>
>> Hm, we do not have aarch64 support in upstream (yet). There is even no
>> dynamic ftrace with regs yet (if I am not mistaken).
>
> I'm curious, how was this tested? Since there is no dynamic ftrace
> with regs and no livepatch stubs (klp_arch_set_pc, etc) implemented
> yet for aarch64. Also, livepatch has switched from klp_relocs/dynrelas
> to .klp.rela. sections since 4.7, so I'm curious how your patch module
> has a .kpatch.dynrelas section working with livepatch.
>
> Unrelated to this patch, if there is a working aarch64 livepatch port (and
> kpatch build tool, it seems) floating out there, it would be
> wonderful to push that upstream :-)
Yeah, from 2014, we started to work on livepatch support on aarch64, and
in May 2015, we pushed the solution to the livepatch community[1] and gcc
community (mfentry feature on aarch64)[2]. And then, there were an another
gcc solution from linaro [3], which proposes to implement a new option
-fprolog-pad=N that generate a pad of N nops at the beginning of each
function, and AFAIK, Torsten Duwe from SUSE is still discussing this method
with gcc community.
At this stage, we are validating the livepatch support on aarch64 based on
aarch64 mfentry feature. When the community has a clear plan, we are happy
to make adaptation and contribute our related work to the community, including
the kpatch-build support :-)
[1] livepatch: add support on arm64
https://lkml.org/lkml/2015/5/28/54
[2] [AArch64] support -mfentry feature for arm64
https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00756.html
[3] Kernel livepatching support in GCC
https://gcc.gnu.org/ml/gcc/2015-05/msg00267.html
[4] arm64: ftrace with regs for livepatch support
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/401352.html
Thanks,
Li Bin
>
> Jessica
>
> .
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] reduce the time of finding symbols for module
2017-03-29 1:50 ` Li Bin
@ 2017-03-29 19:09 ` Jessica Yu
2017-10-13 12:54 ` Ruslan Bilovol
1 sibling, 0 replies; 12+ messages in thread
From: Jessica Yu @ 2017-03-29 19:09 UTC (permalink / raw)
To: Li Bin
Cc: Miroslav Benes, zhouchengming, live-patching, linux-kernel,
jpoimboe, jikos, pmladek, Zefan Li, Hanjun Guo, duwe
+++ Li Bin [29/03/17 09:50 +0800]:
>Hi,
>
>on 2017/3/29 8:03, Jessica Yu wrote:
>> +++ Miroslav Benes [28/03/17 13:16 +0200]:
>>> On Tue, 28 Mar 2017, zhouchengming wrote:
>>>
>>>> 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.
>>>
>>> Ok, it means that you have a lot of relocation records which reference
>>> your out-of-tree module. Then for each such entry klp_resolve_symbol()
>>> is called and then klp_find_object_symbol() to actually resolve it. So if
>>> you have 20k entries, you walk through vmlinux kallsyms table 20k times.
>>> It is unneeded and that is why your fix works.
>>>
>>> But if there were 20k modules loaded, the problem would still be there.
>>>
>>> I think it would be really nice to fix kallsyms :). Replace ordinary array
>>> and the linear search with a hash table.
>>>
>>>> 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
>>>
>>> Hm, we do not have aarch64 support in upstream (yet). There is even no
>>> dynamic ftrace with regs yet (if I am not mistaken).
>>
>> I'm curious, how was this tested? Since there is no dynamic ftrace
>> with regs and no livepatch stubs (klp_arch_set_pc, etc) implemented
>> yet for aarch64. Also, livepatch has switched from klp_relocs/dynrelas
>> to .klp.rela. sections since 4.7, so I'm curious how your patch module
>> has a .kpatch.dynrelas section working with livepatch.
>>
>> Unrelated to this patch, if there is a working aarch64 livepatch port (and
>> kpatch build tool, it seems) floating out there, it would be
>> wonderful to push that upstream :-)
>
>Yeah, from 2014, we started to work on livepatch support on aarch64, and
>in May 2015, we pushed the solution to the livepatch community[1] and gcc
>community (mfentry feature on aarch64)[2]. And then, there were an another
>gcc solution from linaro [3], which proposes to implement a new option
>-fprolog-pad=N that generate a pad of N nops at the beginning of each
>function, and AFAIK, Torsten Duwe from SUSE is still discussing this method
>with gcc community.
>
>At this stage, we are validating the livepatch support on aarch64 based on
>aarch64 mfentry feature. When the community has a clear plan, we are happy
>to make adaptation and contribute our related work to the community, including
>the kpatch-build support :-)
Thanks for the summary and update, it's very helpful. Looking forward
to those patches in the future :-)
>[1] livepatch: add support on arm64
>https://lkml.org/lkml/2015/5/28/54
>[2] [AArch64] support -mfentry feature for arm64
>https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00756.html
>[3] Kernel livepatching support in GCC
>https://gcc.gnu.org/ml/gcc/2015-05/msg00267.html
>[4] arm64: ftrace with regs for livepatch support
>http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/401352.html
>
>Thanks,
>Li Bin
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] reduce the time of finding symbols for module
2017-03-29 1:50 ` Li Bin
2017-03-29 19:09 ` Jessica Yu
@ 2017-10-13 12:54 ` Ruslan Bilovol
2017-10-13 13:18 ` Torsten Duwe
1 sibling, 1 reply; 12+ messages in thread
From: Ruslan Bilovol @ 2017-10-13 12:54 UTC (permalink / raw)
To: Li Bin
Cc: Jessica Yu, Miroslav Benes, zhouchengming, live-patching,
linux-kernel, jpoimboe, jikos, pmladek, Zefan Li, Hanjun Guo,
duwe, rbilovol
Hi Li,
On Wed, Mar 29, 2017 at 4:50 AM, Li Bin <huawei.libin@huawei.com> wrote:
> Hi,
[snip]
>
> Yeah, from 2014, we started to work on livepatch support on aarch64, and
> in May 2015, we pushed the solution to the livepatch community[1] and gcc
> community (mfentry feature on aarch64)[2]. And then, there were an another
> gcc solution from linaro [3], which proposes to implement a new option
> -fprolog-pad=N that generate a pad of N nops at the beginning of each
> function, and AFAIK, Torsten Duwe from SUSE is still discussing this method
> with gcc community.
>
> At this stage, we are validating the livepatch support on aarch64 based on
> aarch64 mfentry feature. When the community has a clear plan, we are happy
> to make adaptation and contribute our related work to the community, including
> the kpatch-build support :-)
>
> [1] livepatch: add support on arm64
> https://lkml.org/lkml/2015/5/28/54
> [2] [AArch64] support -mfentry feature for arm64
> https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00756.html
> [3] Kernel livepatching support in GCC
> https://gcc.gnu.org/ml/gcc/2015-05/msg00267.html
> [4] arm64: ftrace with regs for livepatch support
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/401352.html
>
Since there is already -fpatchable-function-entry option committed by Torsten
to gcc on 25 Jul [1], have you restarted your activities with AArch64 livepatch
support?
If yes, I'm interested in testing of that feature/patches on our hardware
[1] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=e6c4532a6d0f79b94f327d4f9a067faf3988a852
Thanks,
Ruslan
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] reduce the time of finding symbols for module
2017-10-13 12:54 ` Ruslan Bilovol
@ 2017-10-13 13:18 ` Torsten Duwe
2017-10-17 12:44 ` Ruslan Bilovol
0 siblings, 1 reply; 12+ messages in thread
From: Torsten Duwe @ 2017-10-13 13:18 UTC (permalink / raw)
To: Ruslan Bilovol
Cc: Li Bin, Jessica Yu, Miroslav Benes, zhouchengming, live-patching,
linux-kernel, jpoimboe, jikos, pmladek, Zefan Li, Hanjun Guo,
rbilovol
On Fri, Oct 13, 2017 at 03:54:46PM +0300, Ruslan Bilovol wrote:
> Hi Li,
>
> On Wed, Mar 29, 2017 at 4:50 AM, Li Bin <huawei.libin@huawei.com> wrote:
> > Hi,
> [snip]
> >
> > Yeah, from 2014, we started to work on livepatch support on aarch64, and
> > in May 2015, we pushed the solution to the livepatch community[1] and gcc
> > community (mfentry feature on aarch64)[2]. And then, there were an another
> > gcc solution from linaro [3], which proposes to implement a new option
> > -fprolog-pad=N that generate a pad of N nops at the beginning of each
> > function, and AFAIK, Torsten Duwe from SUSE is still discussing this method
> > with gcc community.
> >
> > At this stage, we are validating the livepatch support on aarch64 based on
> > aarch64 mfentry feature. When the community has a clear plan, we are happy
> > to make adaptation and contribute our related work to the community, including
> > the kpatch-build support :-)
> >
> > [1] livepatch: add support on arm64
> > https://lkml.org/lkml/2015/5/28/54
> > [2] [AArch64] support -mfentry feature for arm64
> > https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00756.html
> > [3] Kernel livepatching support in GCC
> > https://gcc.gnu.org/ml/gcc/2015-05/msg00267.html
> > [4] arm64: ftrace with regs for livepatch support
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/401352.html
> >
>
> Since there is already -fpatchable-function-entry option committed by Torsten
> to gcc on 25 Jul [1], have you restarted your activities with AArch64 livepatch
> support?
> If yes, I'm interested in testing of that feature/patches on our hardware
I also have the coresponding kernel patch(es) here. IIRC I already sent
tham to LKML. I'll re-send them once there are more gcc's with -fpatchable-function-entry
support out there.
Torsten
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] reduce the time of finding symbols for module
2017-10-13 13:18 ` Torsten Duwe
@ 2017-10-17 12:44 ` Ruslan Bilovol
2017-10-17 13:06 ` Torsten Duwe
0 siblings, 1 reply; 12+ messages in thread
From: Ruslan Bilovol @ 2017-10-17 12:44 UTC (permalink / raw)
To: Torsten Duwe, Ruslan Bilovol
Cc: Li Bin, Jessica Yu, Miroslav Benes, zhouchengming, live-patching,
linux-kernel, jpoimboe, jikos, pmladek, Zefan Li, Hanjun Guo
Hi,
On 10/13/2017 04:18 PM, Torsten Duwe wrote:
> On Fri, Oct 13, 2017 at 03:54:46PM +0300, Ruslan Bilovol wrote:
>> Hi Li,
>>
>> On Wed, Mar 29, 2017 at 4:50 AM, Li Bin <huawei.libin@huawei.com> wrote:
>>> Hi,
>> [snip]
>>>
>>> Yeah, from 2014, we started to work on livepatch support on aarch64, and
>>> in May 2015, we pushed the solution to the livepatch community[1] and gcc
>>> community (mfentry feature on aarch64)[2]. And then, there were an another
>>> gcc solution from linaro [3], which proposes to implement a new option
>>> -fprolog-pad=N that generate a pad of N nops at the beginning of each
>>> function, and AFAIK, Torsten Duwe from SUSE is still discussing this method
>>> with gcc community.
>>>
>>> At this stage, we are validating the livepatch support on aarch64 based on
>>> aarch64 mfentry feature. When the community has a clear plan, we are happy
>>> to make adaptation and contribute our related work to the community, including
>>> the kpatch-build support :-)
>>>
>>> [1] livepatch: add support on arm64
>>> https://lkml.org/lkml/2015/5/28/54
>>> [2] [AArch64] support -mfentry feature for arm64
>>> https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00756.html
>>> [3] Kernel livepatching support in GCC
>>> https://gcc.gnu.org/ml/gcc/2015-05/msg00267.html
>>> [4] arm64: ftrace with regs for livepatch support
>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/401352.html
>>>
>>
>> Since there is already -fpatchable-function-entry option committed by Torsten
>> to gcc on 25 Jul [1], have you restarted your activities with AArch64 livepatch
>> support?
>> If yes, I'm interested in testing of that feature/patches on our hardware
>
> I also have the coresponding kernel patch(es) here. IIRC I already sent
> tham to LKML. I'll re-send them once there are more gcc's with -fpatchable-function-entry
> support out there.
Do you mean "[PATCH v3 0/2] arm64 live patching" [1] series?
I'm going to play with them and see how it works.
Another question: have you tested livepatching on Big Endian systems?
[1] https://lwn.net/Articles/697050
Thanks,
Ruslan
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] reduce the time of finding symbols for module
2017-10-17 12:44 ` Ruslan Bilovol
@ 2017-10-17 13:06 ` Torsten Duwe
0 siblings, 0 replies; 12+ messages in thread
From: Torsten Duwe @ 2017-10-17 13:06 UTC (permalink / raw)
To: Ruslan Bilovol
Cc: Ruslan Bilovol, Li Bin, Jessica Yu, Miroslav Benes,
zhouchengming, live-patching, linux-kernel, jpoimboe, jikos,
pmladek, Zefan Li, Hanjun Guo
On Tue, Oct 17, 2017 at 03:44:21PM +0300, Ruslan Bilovol wrote:
> On 10/13/2017 04:18 PM, Torsten Duwe wrote:
> >
> > I also have the coresponding kernel patch(es) here. IIRC I already sent
> > tham to LKML. I'll re-send them once there are more gcc's with -fpatchable-function-entry
> > support out there.
>
> Do you mean "[PATCH v3 0/2] arm64 live patching" [1] series?
Yes. With current kernel and updated compiler patching, you'll have to
adjust the naming, but that should basically be it.
> I'm going to play with them and see how it works.
>
> Another question: have you tested livepatching on Big Endian systems?
No. If there are any endian issues, let me know!
Torsten
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2017-10-17 13:06 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-28 2:02 [PATCH] reduce the time of finding symbols for module Zhou Chengming
2017-03-28 9:00 ` Miroslav Benes
2017-03-28 10:58 ` zhouchengming
2017-03-28 11:16 ` Miroslav Benes
2017-03-28 12:50 ` zhouchengming
2017-03-29 0:03 ` Jessica Yu
2017-03-29 1:50 ` Li Bin
2017-03-29 19:09 ` Jessica Yu
2017-10-13 12:54 ` Ruslan Bilovol
2017-10-13 13:18 ` Torsten Duwe
2017-10-17 12:44 ` Ruslan Bilovol
2017-10-17 13:06 ` Torsten Duwe
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.