Messages in this thread | | | Date | Wed, 31 Aug 2022 16:28:56 +0800 | Subject | Re: [PATCH] arch/riscv: kprobes: implement optprobes | From | "liaochang (A)" <> |
| |
在 2022/8/31 15:52, Conor.Dooley@microchip.com 写道: > On 31/08/2022 08:49, liaochang (A) wrote: >> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe >> >> 在 2022/8/31 15:24, Conor.Dooley@microchip.com 写道: >>> Hey Chen, >>> >>> FYI there is a build warning with this patch: >>> arch/riscv/kernel/probes/opt.c:34:27: warning: no previous prototype for 'can_kprobe_direct_exec' [-Wmissing-prototypes] >>> 34 | enum probe_insn __kprobes can_kprobe_direct_exec(kprobe_opcode_t *addr) >>> >>> Also, if you run scripts/checkpatch.pl --strict, it will have a >>> few complaints about code style for you too. Other than that, I >>> have a few comments for you below: >>> >>> On 31/08/2022 05:10, Chen Guokai wrote: >>>> [You don't often get email from chenguokai17@mails.ucas.ac.cn. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] >>>> >>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe >>>> >>>> This patch adds jump optimization support for RISC-V. >>> >>> s/This patch adds/Add >>> >>>> >>>> This patch replaces ebreak instructions used by normal kprobes with an >>> >>> s/This patch replaces/Replace >>> >>>> auipc+jalr instruction pair, at the aim of suppressing the probe-hit >>>> overhead. >>>> >>>> All known optprobe-capable RISC architectures have been using a single >>>> jump or branch instructions while this patch chooses not. RISC-V has a >>>> quite limited jump range (4KB or 2MB) for both its branch and jump >>>> instructions, which prevent optimizations from supporting probes that >>>> spread all over the kernel. >>>> >>>> Auipc-jalr instruction pair is introduced with a much wider jump range >>>> (4GB), where auipc loads the upper 12 bits to a free register and jalr >>>> appends the lower 20 bits to form a 32 bit immediate. Note that returning >>>> from probe handler requires another free register. As kprobes can appear >>>> almost anywhere inside the kernel, the free register should be found in a >>>> generic way, not depending on calling convension or any other regulations. >>> >>> convention >>> >>>> >>>> The algorithm for finding the free register is inspired by the regiter >>> >>> register >>> >>>> renaming in modern processors. From the perspective of register renaming, a >>>> register could be represented as two different registers if two neighbour >>>> instructions both write to it but no one ever reads. Extending this fact, >>>> a register is considered to be free if there is no read before its next >>>> write in the execution flow. We are free to change its value without >>>> interfering normal execution. >>>> >>>> Static analysis shows that 51% instructions of the kernel (default config) >>>> is capable of being replaced i.e. two free registers can be found at both >>>> the start and end of replaced instruction pairs while the replaced >>>> instructions can be directly executed. >>>> >>>> Signed-off-by: Chen Guokai <chenguokai17@mails.ucas.ac.cn> >>>> Signed-off-by: Liao Chang <liaochang1@huawei.com> >>> >>> What does Liao have to do with this patch? >> I just provide some suggestion to Chen Guokai during development ;) >> please remove my info from Signed-off-by tag. > > Does that mean that the "copyright 2022 Huawei" is also not accurate? Inaccurate, please remove "copyright 2022 Huawei",thanks for checking.
> > >
-- BR, Liao, Chang
| |