andy205214
andy205214

Linux内核调试技术——kprobe使用与实现

Linux kprobes调试技术是内核开发者们专门为了便于跟踪内核函数执行状态所设计的一种轻量级内核调试技术。利用kprobes技术，内核开发人员可以在内核的绝大多数指定函数中动态的插入探测点来收集所需的调试状态信息而基本不影响内核原有的执行流程。kprobes技术目前提供了3种探测手段：kprobe、jprobe和kretprobe，其中jprobe和kretprobe是基于kprobe实现的，他们分别应用于不同的探测场景中。本文首先简单描述这3种探测技术的原理与区别，然后主要围绕其中的kprobe技术进行分析并给出一个简单的实例介绍如何利用kprobe进行内核函数探测，最后分析kprobe的实现过程（jprobe和kretprobe会在后续的博文中进行分析）。

内核源码：linux-4.1.15

实验环境：CentOS（x86_64）、树莓派1b


一、kprobes技术背景

开发人员在内核或者模块的调试过程中，往往会需要要知道其中的一些函数有无被调用、何时被调用、执行是否正确以及函数的入参和返回值是什么等等。比较简单的做法是在内核代码对应的函数中添加日志打印信息，但这种方式往往需要重新编译内核或模块，重新启动设备之类的，操作较为复杂甚至可能会破坏原有的代码执行过程。

而利用kprobes技术，用户可以定义自己的回调函数，然后在内核或者模块中几乎所有的函数中（有些函数是不可探测的，例如kprobes自身的相关实现函数，后文会有详细说明）动态的插入探测点，当内核执行流程执行到指定的探测函数时，会调用该回调函数，用户即可收集所需的信息了，同时内核最后还会回到原本的正常执行流程。如果用户已经收集足够的信息，不再需要继续探测，则同样可以动态的移除探测点。因此kprobes技术具有对内核执行流程影响小和操作方便的优点。

kprobes技术包括的3种探测手段分别时kprobe、jprobe和kretprobe。首先kprobe是最基本的探测方式，是实现后两种的基础，它可以在任意的位置放置探测点（就连函数内部的某条指令处也可以），它提供了探测点的调用前、调用后和内存访问出错3种回调方式，分别是pre_handler、post_handler和fault_handler，其中pre_handler函数将在被探测指令被执行前回调，post_handler会在被探测指令执行完毕后回调（注意不是被探测函数），fault_handler会在内存访问出错时被调用；jprobe基于kprobe实现，它用于获取被探测函数的入参值；最后kretprobe从名字种就可以看出其用途了，它同样基于kprobe实现，用于获取被探测函数的返回值。

kprobes的技术原理并不仅仅包含存软件的实现方案，它也需要硬件架构提供支持。其中涉及硬件架构相关的是CPU的异常处理和单步调试技术，前者用于让程序的执行流程陷入到用户注册的回调函数中去，而后者则用于单步执行被探测点指令，因此并不是所有的架构均支持，目前kprobes技术已经支持多种架构，包括i386、x86_64、ppc64、ia64、sparc64、arm、ppc和mips（有些架构实现可能并不完全，具体可参考内核的Documentation/kprobes.txt）。

kprobes的特点与使用限制：

1、kprobes允许在同一个被被探测位置注册多个kprobe，但是目前jprobe却不可以；同时也不允许以其他的jprobe回掉函数和kprobe的post_handler回调函数作为被探测点。

2、一般情况下，可以探测内核中的任何函数，包括中断处理函数。不过在kernel/kprobes.c和arch/*/kernel/kprobes.c程序中用于实现kprobes自身的函数是不允许被探测的，另外还有do_page_fault和notifier_call_chain；

3、如果以一个内联函数为探测点，则kprobes可能无法保证对该函数的所有实例都注册探测点。由于gcc可能会自动将某些函数优化为内联函数，因此可能无法达到用户预期的探测效果；

4、一个探测点的回调函数可能会修改被探测函数运行的上下文，例如通过修改内核的数据结构或者保存与struct pt_regs结构体中的触发探测之前寄存器信息。因此kprobes可以被用来安装bug修复代码或者注入故障测试代码；

5、kprobes会避免在处理探测点函数时再次调用另一个探测点的回调函数，例如在printk()函数上注册了探测点，则在它的回调函数中可能再次调用printk函数，此时将不再触发printk探测点的回调，仅仅时增加了kprobe结构体中nmissed字段的数值；

6、在kprobes的注册和注销过程中不会使用mutex锁和动态的申请内存；

7、kprobes回调函数的运行期间是关闭内核抢占的，同时也可能在关闭中断的情况下执行，具体要视CPU架构而定。因此不论在何种情况下，在回调函数中不要调用会放弃CPU的函数（如信号量、mutex锁等）；

8、kretprobe通过替换返回地址为预定义的trampoline的地址来实现，因此栈回溯和gcc内嵌函数__builtin_return_address()调用将返回trampoline的地址而不是真正的被探测函数的返回地址；

9、如果一个函数的调用此处和返回次数不相等，则在类似这样的函数上注册kretprobe将可能不会达到预期的效果，例如do_exit()函数会存在问题，而do_execve()函数和do_fork()函数不会；

10、如果当在进入和退出一个函数时，CPU运行在非当前任务所有的栈上，那么往该函数上注册kretprobe可能会导致不可预料的后果，因此，kprobes不支持在X86_64的结构下为__switch_to()函数注册kretprobe，将直接返回-EINVAL。


二、kprobe原理

下面来介绍一下kprobe是如何工作的。具体流程见下图：


图1 kprobe的工作流程

1、当用户注册一个探测点后，kprobe首先备份被探测点的对应指令，然后将原始指令的入口点替换为断点指令，该指令是CPU架构相关的，如i386和x86_64是int3，arm是设置一个未定义指令（目前的x86_64架构支持一种跳转优化方案Jump Optimization，内核需开启CONFIG_OPTPROBES选项，该种方案使用跳转指令来代替断点指令）；

2、当CPU流程执行到探测点的断点指令时，就触发了一个trap，在trap处理流程中会保存当前CPU的寄存器信息并调用对应的trap处理函数，该处理函数会设置kprobe的调用状态并调用用户注册的pre_handler回调函数，kprobe会向该函数传递注册的struct kprobe结构地址以及保存的CPU寄存器信息；

3、随后kprobe单步执行前面所拷贝的被探测指令，具体执行方式各个架构不尽相同，arm会在异常处理流程中使用模拟函数执行，而x86_64架构则会设置单步调试flag并回到异常触发前的流程中执行；

4、在单步执行完成后，kprobe执行用户注册的post_handler回调函数；

5、最后，执行流程回到被探测指令之后的正常流程继续执行。


三、kprobe使用实例

在分析kprobe的实现之前先来看一下如何利用kprobe对函数进行探测，以便于让我们对kprobre所完成功能有一个比较清晰的认识。目前，使用kprobe可以通过两种方式，第一种是开发人员自行编写内核模块，向内核注册探测点，探测函数可根据需要自行定制，使用灵活方便；第二种方式是使用kprobes on ftrace，这种方式是kprobe和ftrace结合使用，即可以通过kprobe来优化ftrace来跟踪函数的调用。下面来分别介绍：

1、编写kprobe探测模块

内核提供了一个struct kprobe结构体以及一系列的内核API函数接口，用户可以通过这些接口自行实现探测回调函数并实现struct kprobe结构，然后将它注册到内核的kprobes子系统中来达到探测的目的。同时在内核的samples/kprobes目录下有一个例程kprobe_example.c描述了kprobe模块最简单的编写方式，开发者可以以此为模板编写自己的探测模块。

1.1、kprobe结构体与API介绍

struct kprobe结构体定义如下：

[cpp] view plain copy
  1. struct kprobe {  
  2.     struct hlist_node hlist;  
  3.   
  4.     /* list of kprobes for multi-handler support */  
  5.     struct list_head list;  
  6.   
  7.     /*count the number of times this probe was temporarily disarmed */  
  8.     unsigned long nmissed;  
  9.   
  10.     /* location of the probe point */  
  11.     kprobe_opcode_t *addr;  
  12.   
  13.     /* Allow user to indicate symbol name of the probe point */  
  14.     const char *symbol_name;  
  15.   
  16.     /* Offset into the symbol */  
  17.     unsigned int offset;  
  18.   
  19.     /* Called before addr is executed. */  
  20.     kprobe_pre_handler_t pre_handler;  
  21.   
  22.     /* Called after addr is executed, unless... */  
  23.     kprobe_post_handler_t post_handler;  
  24.   
  25.     /* 
  26.      * ... called if executing addr causes a fault (eg. page fault). 
  27.      * Return 1 if it handled fault, otherwise kernel will see it. 
  28.      */  
  29.     kprobe_fault_handler_t fault_handler;  
  30.   
  31.     /* 
  32.      * ... called if breakpoint trap occurs in probe handler. 
  33.      * Return 1 if it handled break, otherwise kernel will see it. 
  34.      */  
  35.     kprobe_break_handler_t break_handler;  
  36.   
  37.     /* Saved opcode (which has been replaced with breakpoint) */  
  38.     kprobe_opcode_t opcode;  
  39.   
  40.     /* copy of the original instruction */  
  41.     struct arch_specific_insn ainsn;  
  42.   
  43.     /* 
  44.      * Indicates various status flags. 
  45.      * Protected by kprobe_mutex after this kprobe is registered. 
  46.      */  
  47.     u32 flags;  
  48. };  
其中各个字段的含义如下：

struct hlist_node hlist：被用于kprobe全局hash，索引值为被探测点的地址；
struct list_head list：用于链接同一被探测点的不同探测kprobe；
kprobe_opcode_t *addr：被探测点的地址；
const char *symbol_name：被探测函数的名字；
unsigned int offset：被探测点在函数内部的偏移，用于探测函数内部的指令，如果该值为0表示函数的入口；
kprobe_pre_handler_t pre_handler：在被探测点指令执行之前调用的回调函数；
kprobe_post_handler_t post_handler：在被探测指令执行之后调用的回调函数；
kprobe_fault_handler_t fault_handler：在执行pre_handler、post_handler或单步执行被探测指令时出现内存异常则会调用该回调函数；
kprobe_break_handler_t break_handler：在执行某一kprobe过程中触发了断点指令后会调用该函数，用于实现jprobe；
kprobe_opcode_t opcode：保存的被探测点原始指令；
struct arch_specific_insn ainsn：被复制的被探测点的原始指令，用于单步执行，架构强相关（可能包含指令模拟函数）；
u32 flags：状态标记。

涉及的API函数接口如下：

[cpp] view plain copy
  1. int register_kprobe(struct kprobe *kp)      //向内核注册kprobe探测点  
  2. void unregister_kprobe(struct kprobe *kp)   //卸载kprobe探测点  
  3. int register_kprobes(struct kprobe **kps, int num)     //注册探测函数向量，包含多个探测点  
  4. void unregister_kprobes(struct kprobe **kps, int num)  //卸载探测函数向量，包含多个探测点  
  5. int disable_kprobe(struct kprobe *kp)       //临时暂停指定探测点的探测  
  6. int enable_kprobe(struct kprobe *kp)        //恢复指定探测点的探测  

1.2、用例kprobe_example.c分析与演示

该用例函数非常简单，它实现了内核函数do_fork的探测，该函数会在fork系统调用或者内核kernel_thread函数创建进程时被调用，触发也十分的频繁。下面来分析一下用例代码：

[cpp] view plain copy
  1. /* For each probe you need to allocate a kprobe structure */  
  2. static struct kprobe kp = {  
  3.     .symbol_name    = "do_fork",  
  4. };  
  5.   
  6. static int __init kprobe_init(void)  
  7. {  
  8.     int ret;  
  9.     kp.pre_handler = handler_pre;  
  10.     kp.post_handler = handler_post;  
  11.     kp.fault_handler = handler_fault;  
  12.   
  13.     ret = register_kprobe(&kp);  
  14.     if (ret < 0) {  
  15.         printk(KERN_INFO "register_kprobe failed, returned %d\n", ret);  
  16.         return ret;  
  17.     }  
  18.     printk(KERN_INFO "Planted kprobe at %p\n", kp.addr);  
  19.     return 0;  
  20. }  
  21.   
  22. static void __exit kprobe_exit(void)  
  23. {  
  24.     unregister_kprobe(&kp);  
  25.     printk(KERN_INFO "kprobe at %p unregistered\n", kp.addr);  
  26. }  
  27.   
  28. module_init(kprobe_init)  
  29. module_exit(kprobe_exit)  
  30. MODULE_LICENSE("GPL");  
程序中定义了一个struct kprobe结构实例kp并初始化其中的symbol_name字段为“do_fork”，表明它将要探测do_fork函数。在模块的初始化函数中，注册了
pre_handler、post_handler和fault_handler这3个回调函数分别为handler_pre、handler_post和handler_fault，最后调用register_kprobe注册。在模块的卸载函数中调用unregister_kprobe函数卸载kp探测点。
[cpp] view plain copy
  1. static int handler_pre(struct kprobe *p, struct pt_regs *regs)  
  2. {  
  3. #ifdef CONFIG_X86  
  4.     printk(KERN_INFO "pre_handler: p->addr = 0x%p, ip = %lx,"  
  5.             " flags = 0x%lx\n",  
  6.         p->addr, regs->ip, regs->flags);  
  7. #endif  
  8. #ifdef CONFIG_PPC  
  9.     printk(KERN_INFO "pre_handler: p->addr = 0x%p, nip = 0x%lx,"  
  10.             " msr = 0x%lx\n",  
  11.         p->addr, regs->nip, regs->msr);  
  12. #endif  
  13. #ifdef CONFIG_MIPS  
  14.     printk(KERN_INFO "pre_handler: p->addr = 0x%p, epc = 0x%lx,"  
  15.             " status = 0x%lx\n",  
  16.         p->addr, regs->cp0_epc, regs->cp0_status);  
  17. #endif  
  18. #ifdef CONFIG_TILEGX  
  19.     printk(KERN_INFO "pre_handler: p->addr = 0x%p, pc = 0x%lx,"  
  20.             " ex1 = 0x%lx\n",  
  21.         p->addr, regs->pc, regs->ex1);  
  22. #endif  
  23.   
  24.     /* A dump_stack() here will give a stack backtrace */  
  25.     return 0;  
  26. }  
handler_pre回调函数的第一个入参是注册的struct kprobe探测实例，第二个参数是保存的触发断点前的寄存器状态，它在do_fork函数被调用之前被调用，该函数仅仅是打印了被探测点的地址，保存的个别寄存器参数。由于受CPU架构影响，这里对不同的架构进行了宏区分（虽然没有实现arm架构的，但是支持的，可以自行添加）；
[cpp] view plain copy
  1. /* kprobe post_handler: called after the probed instruction is executed */  
  2. static void handler_post(struct kprobe *p, struct pt_regs *regs,  
  3.                 unsigned long flags)  
  4. {  
  5. #ifdef CONFIG_X86  
  6.     printk(KERN_INFO "post_handler: p->addr = 0x%p, flags = 0x%lx\n",  
  7.         p->addr, regs->flags);  
  8. #endif  
  9. #ifdef CONFIG_PPC  
  10.     printk(KERN_INFO "post_handler: p->addr = 0x%p, msr = 0x%lx\n",  
  11.         p->addr, regs->msr);  
  12. #endif  
  13. #ifdef CONFIG_MIPS  
  14.     printk(KERN_INFO "post_handler: p->addr = 0x%p, status = 0x%lx\n",  
  15.         p->addr, regs->cp0_status);  
  16. #endif  
  17. #ifdef CONFIG_TILEGX  
  18.     printk(KERN_INFO "post_handler: p->addr = 0x%p, ex1 = 0x%lx\n",  
  19.         p->addr, regs->ex1);  
  20. #endif  
  21. }  
handler_post回调函数的前两个入参同handler_pre，第三个参数目前尚未使用，全部为0；该函数在do_fork函数调用之后被调用，这里打印的内容同handler_pre类似。
[cpp] view plain copy
  1. /* 
  2.  * fault_handler: this is called if an exception is generated for any 
  3.  * instruction within the pre- or post-handler, or when Kprobes 
  4.  * single-steps the probed instruction. 
  5.  */  
  6. static int handler_fault(struct kprobe *p, struct pt_regs *regs, int trapnr)  
  7. {  
  8.     printk(KERN_INFO "fault_handler: p->addr = 0x%p, trap #%dn",  
  9.         p->addr, trapnr);  
  10.     /* Return 0 because we don't handle the fault. */  
  11.     return 0;  
  12. }  
handler_fault回调函数会在执行handler_pre、handler_post或单步执行do_fork时出现错误时调用，这里第三个参数时具体发生错误的trap number，与架构相关，例如i386的page fault为14。

下面将它编译成模块在我的x86（CentOS 3.10）环境下进行演示，首先确保架构和内核已经支持kprobes，开启以下选项（一般都是默认开启的）：

Symbol: KPROBES [=y]                            
Type  : boolean                                 
Prompt: Kprobes                                 
  Location:                                     
(3) -> General setup                            
  Defined at arch/Kconfig:37                    
  Depends on: MODULES [=y] && HAVE_KPROBES [=y] 
  Selects: KALLSYMS [=y]                        
 
Symbol: HAVE_KPROBES [=y]                       
Type  : boolean                                 
  Defined at arch/Kconfig:174                   
  Selected by: X86 [=y]    

然后使用以下Makefile单独编译kprobe_example.ko模块：

[cpp] view plain copy
  1. obj-m := kprobe_example.o  
  2.   
  3. CROSS_COMPILE=''  
  4.   
  5. KDIR := /lib/modules/$(shell uname -r)/build  
  6. all:  
  7.         make -C $(KDIR) M=$(PWD) modules   
  8. clean:  
  9.         rm -f *.ko *.o *.mod.o *.mod.c .*.cmd *.symvers  modul*  
加载到内核中后，随便在终端上敲一个命令，可以看到dmesg中打印如下信息：

<6>pre_handler: p->addr = 0xc0439cc0, ip = c0439cc1, flags = 0x246
<6>post_handler: p->addr = 0xc0439cc0, flags = 0x246
<6>pre_handler: p->addr = 0xc0439cc0, ip = c0439cc1, flags = 0x246
<6>post_handler: p->addr = 0xc0439cc0, flags = 0x246
<6>pre_handler: p->addr = 0xc0439cc0, ip = c0439cc1, flags = 0x246
<6>post_handler: p->addr = 0xc0439cc0, flags = 0x246

可以看到被探测点的地址为0xc0439cc0，用以下命令确定这个地址就是do_fork的入口地址。

[root@apple kprobes]# cat /proc/kallsyms | grep do_fork
c0439cc0 T do_fork


2、使用kprobe on ftrace来跟踪函数和调用栈

这种方式用户通过/sys/kernel/debug/tracing/目录下的trace等属性文件来探测用户指定的函数，用户可添加kprobe支持的任意函数并设置探测格式与过滤条件，无需再编写内核模块，使用更为简便，但需要内核的debugfs和ftrace功能的支持。

首先，在使用前需要保证开启以下内核选项：

Symbol: FTRACE [=y]                                                                                            
Type  : boolean                                                                                                
Prompt: Tracers                                                                                                
  Location:                                                                                                    
(5) -> Kernel hacking                                                                                          
  Defined at kernel/trace/Kconfig:132                                                                          
  Depends on: TRACING_SUPPORT [=y] 

Symbol: KPROBE_EVENT [=y]                                                                                      
Type  : boolean                                                                                                
Prompt: Enable kprobes-based dynamic events                                                                    
  Location:                                                                                                    
    -> Kernel hacking                                                                                          
(1)   -> Tracers (FTRACE [=y])                                                                                 
  Defined at kernel/trace/Kconfig:405                                                                          
  Depends on: TRACING_SUPPORT [=y] && FTRACE [=y] && KPROBES [=y] && HAVE_REGS_AND_STACK_ACCESS_API [=y]       
  Selects: TRACING [=y] && PROBE_EVENTS [=y]  

Symbol: HAVE_KPROBES_ON_FTRACE [=y]                                                                            
Type  : boolean                                                                                                
  Defined at arch/Kconfig:183                                                                                  
  Selected by: X86 [=y]                                                                                        
 
Symbol: KPROBES_ON_FTRACE [=y]                                                                                 
Type  : boolean                                                                                                
  Defined at arch/Kconfig:79                                                                                   
  Depends on: KPROBES [=y] && HAVE_KPROBES_ON_FTRACE [=y] && DYNAMIC_FTRACE_WITH_REGS [=y]

然后需要将debugfs文件系统挂在到/sys/kernel/debug/目录下：

# mount -t debugfs nodev /sys/kernel/debug/

此时/sys/kernel/debug/tracing目录下就出现了若干个文件和目录用于用户设置要跟踪的函数以及过滤条件等等，这里我主要关注以下几个文件：

1、配置属性文件：kprobe_events
2、查询属性文件：trace和trace_pipe
3、使能属性文件：events/kprobes///enabled
4、过滤属性文件：events/kprobes///filter
5、格式查询属性文件：events/kprobes///format
6、事件统计属性文件：kprobe_profile

其中配置属性文件用于用户配置要探测的函数以及探测的方式与参数，在配置完成后，会在events/kprobes/目录下生成对应的目录；其中会生成enabled、format、filter和id这4个文件，其中的enable属性文件用于控制探测的开启或关闭，filter用于设置过滤条件，format可以查看当前的输出格式，最后id可以查看当前probe event的ID号。然后若被探测函数被执行流程触发调用，用户可以通过trace属性文件进行查看。最后通过kprobe_profile属性文件可以查看探测命中次数和丢失次数（probe hits and probe miss-hits）。

下面来看看各个属性文件的常用操作方式（其中具体格式和参数方面的细节可以查看内核的Documentation/trace/kprobetrace.txt文件，描述非常详细）：

1、kprobe_events

该属性文件支持3中格式的输入：

  p[:[GRP/]EVENT] [MOD:]SYM[+offs]|MEMADDR [FETCHARGS]——设置一个probe探测点
  r[:[GRP/]EVENT] [MOD:]SYM[+0] [FETCHARGS]                         ——设置一个return probe探测点
  -:[GRP/]EVENT                                                 ——删除一个探测点

各个字段的含义如下： 

GRP : Group name. If omitted, use "kprobes" for it.               ——指定后会在events/kprobes目录下生成对应名字的目录，一般不设
 EVENT : Event name. If omitted, the event name is generated based on SYM+offs or MEMADDR.    ——指定后会在events/kprobes/目录下生成对应名字的目录
 MOD : Module name which has given SYM.                             ——模块名，一般不设
 SYM[+offs] : Symbol+offset where the probe is inserted.                 ——指定被探测函数和偏移
 MEMADDR : Address where the probe is inserted.                            ——指定被探测的内存绝对地址

 FETCHARGS : Arguments. Each probe can have up to 128 args.                         ——指定要获取的参数信息
  %REG : Fetch register REG                                                                                       ——获取指定寄存器值
  @ADDR : Fetch memory at ADDR (ADDR should be in kernel)                    ——获取指定内存地址的值
  @SYM[+|-offs] : Fetch memory at SYM +|- offs (SYM should be a data symbol)    ——获取全局变量的值
  $stackN : Fetch Nth entry of stack (N >= 0)                                                                 ——获取指定栈空间值，即sp寄存器+N后的位置值
  $stack : Fetch stack address.                                                                                            ——获取sp寄存器值
  $retval : Fetch return value.(*)                                                                                             ——获取返回值，仅用于return probe
  +|-offs(FETCHARG) : Fetch memory at FETCHARG +|- offs address.(**)                  ——以下可以由于获取指定地址的结构体参数内容，可以设定具体的参数名和偏移地址
  NAME=FETCHARG : Set NAME as the argument name of FETCHARG.
  FETCHARG:TYPE : Set TYPE as the type of FETCHARG. Currently, basic types     ——设置参数的类型，可以支持字符串和比特类型
 (u8/u16/u32/u64/s8/s16/s32/s64), "string" and bitfield
 are supported.

2、events/kprobes///enabled

开启探测：echo 1 > events/kprobes///enabled

暂停探测：echo 0 > events/kprobes///enabled

3、events/kprobes///filter

该属性文件用于设置过滤条件，可以减少trace中输出的信息，它支持的格式和C语言的表达式类似，支持 ==，!=，>，<，>=，<=判断，并且支持与&&，或||，还有()。


下面还是以do_fork()函数为例来举例看一下具体如何使用（实验环境：树莓派1b）：

1、设置配置属性

首先添加配置探测点：

root@apple:~# echo 'p:myprobe do_fork clone_flags=%r0 stack_start=%r1 stack_size=%r2 parent_tidptr=%r3 child_tidptr=+0($stack)' > /sys/kernel/debug/tracing/kprobe_events

root@apple:~# echo 'r:myretprobe do_fork $retval' >> /sys/kernel/debug/tracing/kprobe_events

这里注册probe和retprobe，其中probe中设定了获取do_fork()函数的入参值（注意这里的参数信息根据不同CPU架构的函数参数传递规则强相关，根据ARM遵守的ATPCS规则，函数入参1~4通过r0~r3寄存器传递，多余的参数通过栈传递），由于入参为5个，所以前4个通过寄存器获取，最后一个通过栈获取。

现可通过format文件查看探测的输出格式：

root@apple:/sys/kernel/debug/tracing# cat events/kprobes/myprobe/format 
name: myprobe
ID: 1211
format:
        field:unsigned short common_type;       offset:0;       size:2; signed:0;
        field:unsigned char common_flags;       offset:2;       size:1; signed:0;
        field:unsigned char common_preempt_count;       offset:3;       size:1; signed:0;
        field:int common_pid;   offset:4;       size:4; signed:1;

        field:unsigned long __probe_ip; offset:8;       size:4; signed:0;
        field:u32 clone_flags;  offset:12;      size:4; signed:0;
        field:u32 stack_start;  offset:16;      size:4; signed:0;
        field:u32 stack_size;   offset:20;      size:4; signed:0;
        field:u32 parent_tidptr;        offset:24;      size:4; signed:0;
        field:u32 child_tidptr; offset:28;      size:4; signed:0;

print fmt: "(%lx) clone_flags=0x%x stack_start=0x%x stack_size=0x%x parent_tidptr=0x%x child_tidptr=0x%x", REC->__probe_ip, REC->clone_flags, REC->stack_start, REC->stack_size, REC->parent_tidptr, REC->child_tidptr

root@apple:/sys/kernel/debug/tracing# cat events/kprobes/myretprobe/format     
name: myretprobe
ID: 1212
format:
        field:unsigned short common_type;       offset:0;       size:2; signed:0;
        field:unsigned char common_flags;       offset:2;       size:1; signed:0;
        field:unsigned char common_preempt_count;       offset:3;       size:1; signed:0;
        field:int common_pid;   offset:4;       size:4; signed:1;

        field:unsigned long __probe_func;       offset:8;       size:4; signed:0;
        field:unsigned long __probe_ret_ip;     offset:12;      size:4; signed:0;
        field:u32 arg1; offset:16;      size:4; signed:0;

print fmt: "(%lx <- %lx) arg1=0x%x", REC->__probe_func, REC->__probe_ret_ip, REC->arg1

2、开启探测并触发函数调用

往对应的enable函数中写入1用以开启探测功能：

root@apple:/sys/kernel/debug/tracing# echo 1 > events/kprobes/myprobe/enable 

root@apple:/sys/kernel/debug/tracing# echo 1 > events/kprobes/myretprobe/enable 

然后在终端上敲几条命令和建立一个ssh链接触发进程创建do_fork函数调用，并通过trace属性文件获取函数调用时的探测情况

root@apple:/sys/kernel/debug/tracing# cat trace     

# tracer: nop
......
            bash-513   [000] d... 15726.746135: myprobe: (do_fork+0x0/0x380) clone_flags=0x1200011 stack_start=0x0 stack_size=0x0 parent_tidptr=0x0 child_tidptr=0xb6f43278
            bash-513   [000] d... 15726.746691: myretprobe: (SyS_clone+0x2c/0x34 <- do_fork) arg1=0x226
            bash-513   [000] d... 15727.296153: myprobe: (do_fork+0x0/0x380) clone_flags=0x1200011 stack_start=0x0 stack_size=0x0 parent_tidptr=0x0 child_tidptr=0xb6f43278
            bash-513   [000] d... 15727.296713: myretprobe: (SyS_clone+0x2c/0x34 <- do_fork) arg1=0x227
            bash-513   [000] d... 15728.356149: myprobe: (do_fork+0x0/0x380) clone_flags=0x1200011 stack_start=0x0 stack_size=0x0 parent_tidptr=0x0 child_tidptr=0xb6f43278
            bash-513   [000] d... 15728.356705: myretprobe: (SyS_clone+0x2c/0x34 <- do_fork) arg1=0x228
            bash-513   [000] d... 15731.596195: myprobe: (do_fork+0x0/0x380) clone_flags=0x1200011 stack_start=0x0 stack_size=0x0 parent_tidptr=0x0 child_tidptr=0xb6f43278
            bash-513   [000] d... 15731.596756: myretprobe: (SyS_clone+0x2c/0x34 <- do_fork) arg1=0x229
            sshd-520   [000] d... 17755.999223: myprobe: (do_fork+0x0/0x380) clone_flags=0x1200011 stack_start=0x0 stack_size=0x0 parent_tidptr=0x0 child_tidptr=0xb6fac068
            sshd-520   [000] d... 17755.999943: myretprobe: (SyS_clone+0x2c/0x34 <- do_fork) arg1=0x22d

从输出中可以看到do_fork函数由bash（PID=513) 和sshd（PID=520）进程调用，同时执行的CPU为0，调用do_fork函数是入参值分别是stack_start=0x0 stack_size=0x0 parent_tidptr=0x0 child_tidptr=0xbxxxxxxx，同时输出函数返回上层SyS_clone系统调用的nr值。

如果输出太多了，想要清除就向trace中写0即可

root@apple:/sys/kernel/debug/tracing# echo 0 > trace  

3、使用filter进行过滤

例如想要把前面列出的PID为513调用信息的给过滤掉，则向filter中写入如下的命令即可：

root@apple:/sys/kernel/debug/tracing# echo common_pid!=513 > events/kprobes/myprobe/filter 

root@apple:/sys/kernel/debug/tracing# cat trace
# tracer: nop
......
            bash-513   [000] d... 24456.536804: myretprobe: (SyS_clone+0x2c/0x34 <- do_fork) arg1=0x245
        kthreadd-2     [000] d... 24598.655935: myprobe: (do_fork+0x0/0x380) clone_flags=0x800711 stack_start=0xc003d69c stack_size=0xc58982a0 parent_tidptr=0x0 child_tidptr=0x0
        kthreadd-2     [000] d... 24598.656133: myretprobe: (kernel_thread+0x38/0x40 <- do_fork) arg1=0x246
            bash-513   [000] d... 24667.676717: myretprobe: (SyS_clone+0x2c/0x34 <- do_fork) arg1=0x247

如此就不会在打印PID为513的进程调用信息了，这里的参数可以参考前面的format中输出的，例如想指定输出特定clone_flags值，则可以输入clone_flags=xxx即可。

最后补充一点，若此时需要查看函数调用的栈信息（stacktrace），可以使用如下命令激活stacktrace输出：

root@apple:/sys/kernel/debug/tracing# echo stacktrace > trace_options

root@apple:/sys/kernel/debug/tracing# cat trace                                
......
            bash-508   [000] d...   449.276093: myprobe: (do_fork+0x0/0x380) clone_flags=0x1200011 stack_start=0x0 stack_size=0x0 parent_tidptr=0x0 child_tidptr=0xb6f86278
            bash-508   [000] d...   449.276126:
 => do_fork


四、kprobe实现源码分析

在了解了kprobe的基本原理和使用后，现在从源码的角度来详细分析它是如何实现的。主要包括kprobes的初始化、注册kprobe和触发kprobe（包括arm结构和x86_64架构的回调函数和single-step单步执行）。

1、kprobes初始化


图 2 kprobes初始化流程 

kprobes作为一个模块，其初始化函数为init_kprobes，代码路径kernel/kprobes.c

[cpp] view plain copy
  1. static int __init init_kprobes(void)  
  2. {  
  3.     int i, err = 0;  
  4.   
  5.     /* FIXME allocate the probe table, currently defined statically */  
  6.     /* initialize all list heads */  
  7.     for (i = 0; i < KPROBE_TABLE_SIZE; i++) {  
  8.         INIT_HLIST_HEAD(&kprobe_table[i]);  
  9.         INIT_HLIST_HEAD(&kretprobe_inst_table[i]);  
  10.         raw_spin_lock_init(&(kretprobe_table_locks[i].lock));  
  11.     }  
  12.   
  13.     err = populate_kprobe_blacklist(__start_kprobe_blacklist,  
  14.                     __stop_kprobe_blacklist);  
  15.     if (err) {  
  16.         pr_err("kprobes: failed to populate blacklist: %d\n", err);  
  17.         pr_err("Please take care of using kprobes.\n");  
  18.     }  
  19.   
  20.     if (kretprobe_blacklist_size) {  
  21.         /* lookup the function address from its name */  
  22.         for (i = 0; kretprobe_blacklist[i].name != NULL; i++) {  
  23.             kprobe_lookup_name(kretprobe_blacklist[i].name,  
  24.                        kretprobe_blacklist[i].addr);  
  25.             if (!kretprobe_blacklist[i].addr)  
  26.                 printk("kretprobe: lookup failed: %s\n",  
  27.                        kretprobe_blacklist[i].name);  
  28.         }  
  29.     }  
  30.   
  31. #if defined(CONFIG_OPTPROBES)  
  32. #if defined(__ARCH_WANT_KPROBES_INSN_SLOT)  
  33.     /* Init kprobe_optinsn_slots */  
  34.     kprobe_optinsn_slots.insn_size = MAX_OPTINSN_SIZE;  
  35. #endif  
  36.     /* By default, kprobes can be optimized */  
  37.     kprobes_allow_optimization = true;  
  38. #endif  
  39.   
  40.     /* By default, kprobes are armed */  
  41.     kprobes_all_disarmed = false;  
  42.   
  43.     err = arch_init_kprobes();  
  44.     if (!err)  
  45.         err = register_die_notifier(&kprobe_exceptions_nb);  
  46.     if (!err)  
  47.         err = register_module_notifier(&kprobe_module_nb);  
  48.   
  49.     kprobes_initialized = (err == 0);  
  50.   
  51.     if (!err)  
  52.         init_test_probes();  
  53.     return err;  
  54. }  
首先初始化hash表的各个链表头，用来保存后面调用kprobe_register函数注册的struct kprobes实例（会使用探测地址作为索引），同时初始化kretprobe用到的自旋锁。
接下来调用populate_kprobe_blacklist函数将kprobe实现相关的代码函数保存到kprobe_blacklist这个链表中去，用于后面注册探测点时判断使用，注意这里的__start_kprobe_blacklist和__stop_kprobe_blacklist定义在arch/arm/kernel/vmlinux.lds.h中的.init.rodata段中，其中保存了_kprobe_blacklist段信息：
[cpp] view plain copy
  1. #define KPROBE_BLACKLIST()  . = ALIGN(8);                     \  
  2.                 VMLINUX_SYMBOL(__start_kprobe_blacklist) = .; \  
  3.                 *(_kprobe_blacklist)                  \  
  4.                 VMLINUX_SYMBOL(__stop_kprobe_blacklist) = .;  
  5.   
  6. #define INIT_DATA                           \  
  7.     *(.init.data)                           \  
  8. ......  
  9.     *(.init.rodata)                         \  
  10. ......  
  11.     KPROBE_BLACKLIST()                      \  
  12. ......  
而_kprobe_blacklist段中保存了实现kprobes的关键代码路径，这些代码是不可以被kprobe自己所探测的，在源码定义相关函数时使用NOKPROBE_SYMBOL宏将函数放到这个段中：
[cpp] view plain copy
  1. #define __NOKPROBE_SYMBOL(fname)            \  
  2. static unsigned long __used             \  
  3.     __attribute__((section("_kprobe_blacklist")))   \  
  4.     _kbl_addr_##fname = (unsigned long)fname;  
  5. #define NOKPROBE_SYMBOL(fname)  __NOKPROBE_SYMBOL(fname)  
例如其中的get_kprobe函数：
[cpp] view plain copy
  1. struct kprobe *get_kprobe(void *addr)  
  2. {  
  3. ......  
  4. }  
  5. NOKPROBE_SYMBOL(get_kprobe);  

回到init_kprobes函数中继续分析，接下来的片段是kretprobe相关的代码，用来核对kretprobe_blacklist中定义的函数是否存在，这里kretprobe_blacklist_size变量默认为0；接下来初始化3个全局变量，kprobes_all_disarmed用于表示是否启用kprobe机制，这里默认设置为启用；随后调用arch_init_kprobes进行架构相关的初始化，x86架构的实现为空，arm架构的实现如下：

[cpp] view plain copy
  1. int __init arch_init_kprobes()  
  2. {  
  3.     arm_probes_decode_init();  
  4. #ifdef CONFIG_THUMB2_KERNEL  
  5.     register_undef_hook(&kprobes_thumb16_break_hook);  
  6.     register_undef_hook(&kprobes_thumb32_break_hook);  
  7. #else  
  8.     register_undef_hook(&kprobes_arm_break_hook);  
  9. #endif  
  10.     return 0;  
  11. }  
由于没有启用THUMB2模式，这里arm_probes_decode_init主要是获取PC和当前执行地址偏移值（ARM的流水线机制一般为8）以及设置相关寄存器值获取方式等代码；而register_undef_hook函数向全局undef_hook链表注册了一个未定义指令异常处理的钩子，相关的结构体如下：
[cpp] view plain copy
  1. static struct undef_hook kprobes_arm_break_hook = {  
  2.     .instr_mask = 0x0fffffff,  
  3.     .instr_val  = KPROBE_ARM_BREAKPOINT_INSTRUCTION,  
  4.     .cpsr_mask  = MODE_MASK,  
  5.     .cpsr_val   = SVC_MODE,  
  6.     .fn     = kprobe_trap_handler,  
  7. };  
这样在触发未定义指令KPROBE_ARM_BREAKPOINT_INSTRUCTION（机器码0x07f001f8）时将会调用到这里的kprobe_trap_handler函数。

再次回到init_kprobes函数，接下来分别注册die和module的内核通知链kprobe_exceptions_nb和kprobe_module_nb：

[cpp] view plain copy
  1. static struct notifier_block kprobe_exceptions_nb = {  
  2.     .notifier_call = kprobe_exceptions_notify,  
  3.     .priority = 0x7fffffff /* we need to be notified first */  
  4. };  
[cpp] view plain copy
  1. static struct notifier_block kprobe_module_nb = {  
  2.     .notifier_call = kprobes_module_callback,  
  3.     .priority = 0  
  4. };  
其中kprobe_exceptions_nb的优先级很高，如此在执行回调函数和单步执行被探测指令期间若发生了内存异常，将优先调用kprobe_exceptions_notify函数处理（架构相关，x86会调用kprobe的fault回调函数，而arm则为空）；注册module notify回调kprobes_module_callback函数的作用是若当某个内核模块发生卸载操作时有必要检测并移除注册到该模块函数的探测点。

最后init_kprobes函数置位kprobes_initialized标识，初始化完成。


2、注册一个kprobe实例

kprobe探测模块调用register_kprobe向kprobe子系统注册一个kprobe探测点实例，代码路径kernel/kprobes.c


图 3 kprobe注册流程

[cpp] view plain copy
  1. int register_kprobe(struct kprobe *p)  
  2. {  
  3.     int ret;  
  4.     struct kprobe *old_p;  
  5.     struct module *probed_mod;  
  6.     kprobe_opcode_t *addr;  
  7.   
  8.     /* Adjust probe address from symbol */  
  9.     addr = kprobe_addr(p);  
  10.     if (IS_ERR(addr))  
  11.         return PTR_ERR(addr);  
  12.     p->addr = addr;  
  13.   
  14.     ret = check_kprobe_rereg(p);  
  15.     if (ret)  
  16.         return ret;  
  17.   
  18.     /* User can pass only KPROBE_FLAG_DISABLED to register_kprobe */  
  19.     p->flags &= KPROBE_FLAG_DISABLED;  
  20.     p->nmissed = 0;  
  21.     INIT_LIST_HEAD(&p->list);  
  22.   
  23.     ret = check_kprobe_address_safe(p, &probed_mod);  
  24.     if (ret)  
  25.         return ret;  
  26.   
  27.     mutex_lock(&kprobe_mutex);  
  28.   
  29.     old_p = get_kprobe(p->addr);  
  30.     if (old_p) {  
  31.         /* Since this may unoptimize old_p, locking text_mutex. */  
  32.         ret = register_aggr_kprobe(old_p, p);  
  33.         goto out;  
  34.     }  
  35.   
  36.     mutex_lock(&text_mutex);    /* Avoiding text modification */  
  37.     ret = prepare_kprobe(p);  
  38.     mutex_unlock(&text_mutex);  
  39.     if (ret)  
  40.         goto out;  
  41.   
  42.     INIT_HLIST_NODE(&p->hlist);  
  43.     hlist_add_head_rcu(&p->hlist,  
  44.                &kprobe_table[hash_ptr(p->addr, KPROBE_HASH_BITS)]);  
  45.   
  46.     if (!kprobes_all_disarmed && !kprobe_disabled(p))  
  47.         arm_kprobe(p);  
  48.   
  49.     /* Try to optimize kprobe */  
  50.     try_to_optimize_kprobe(p);  
  51.   
  52. out:  
  53.     mutex_unlock(&kprobe_mutex);  
  54.   
  55.     if (probed_mod)  
  56.         module_put(probed_mod);  
  57.   
  58.     return ret;  
  59. }  
  60. EXPORT_SYMBOL_GPL(register_kprobe);  
函数首先调用kprobe_addr函数初始化被探测点的地址p->addr。因为一般的探测模块并不会指定想要探测的addr地址，同kprobe_example例程一样通过传入函数名来指定要探测的函数，kprobe_addr函数的作用就是将函数名转换为最终的被探测地址：
[cpp] view plain copy
  1. #define kprobe_lookup_name(name, addr) \  
  2.     addr = ((kprobe_opcode_t *)(kallsyms_lookup_name(name)))  
  3.       
  4. static kprobe_opcode_t *kprobe_addr(struct kprobe *p)  
  5. {  
  6.     kprobe_opcode_t *addr = p->addr;  
  7.   
  8.     if ((p->symbol_name && p->addr) ||  
  9.         (!p->symbol_name && !p->addr))  
  10.         goto invalid;  
  11.   
  12.     if (p->symbol_name) {  
  13.         kprobe_lookup_name(p->symbol_name, addr);  
  14.         if (!addr)  
  15.             return ERR_PTR(-ENOENT);  
  16.     }  
  17.   
  18.     addr = (kprobe_opcode_t *)(((char *)addr) + p->offset);  
  19.     if (addr)  
  20.         return addr;  
  21.   
  22. invalid:  
  23.     return ERR_PTR(-EINVAL);  
  24. }  

kprobe_addr首先对入参进行检查，不允许函数名和地址同时设置或同时为空的情况；如果用户指定被探测函数名则调用kallsyms_lookup_name函数根据函数名查找其运行的虚拟地址；最后加上指定的探测偏移值作为最终的被探测地址。当然在绝大多数的情况下，offset值被用户设置为0，即用户探测指定函数的入口，但是也不排除用户想要探测某一函数内部的某一条指令。

回到register_kprobe函数中，下面调用check_kprobe_rereg函数防止同一个kprobe实例被重复注册，其中check_kprobe_rereg->__get_valid_kprobe调用流程将根据addr地址值搜索全局hash表并查看是否有同样的kprobe实例已经在表中了。

随后register_kprobe函数继续初始化kprobe的flags、nmissed字段和list链表（flag只允许用户传递KPROBE_FLAG_DISABLED，表示注册的kprobe默认是不启用的），然后调用check_kprobe_address_safe函数检测被探测地址是否可探测：

[cpp] view plain copy
  1. static int check_kprobe_address_safe(struct kprobe *p,  
  2.                      struct module **probed_mod)  
  3. {  
  4.     int ret;  
  5.   
  6.     ret = arch_check_ftrace_location(p);  
  7.     if (ret)  
  8.         return ret;  
  9.     jump_label_lock();  
  10.     preempt_disable();  
  11.   
  12.     /* Ensure it is not in reserved area nor out of text */  
  13.     if (!kernel_text_address((unsigned long) p->addr) ||  
  14.         within_kprobe_blacklist((unsigned long) p->addr) ||  
  15.         jump_label_text_reserved(p->addr, p->addr)) {  
  16.         ret = -EINVAL;  
  17.         goto out;  
  18.     }  
  19.   
  20.     /* Check if are we probing a module */  
  21.     *probed_mod = __module_text_address((unsigned long) p->addr);  
  22.     if (*probed_mod) {  
  23.         /* 
  24.          * We must hold a refcount of the probed module while updating 
  25.          * its code to prohibit unexpected unloading. 
  26.          */  
  27.         if (unlikely(!try_module_get(*probed_mod))) {  
  28.             ret = -ENOENT;  
  29.             goto out;  
  30.         }  
  31.   
  32.         /* 
  33.          * If the module freed .init.text, we couldn't insert 
  34.          * kprobes in there. 
  35.          */  
  36.         if (within_module_init((unsigned long)p->addr, *probed_mod) &&  
  37.             (*probed_mod)->state != MODULE_STATE_COMING) {  
  38.             module_put(*probed_mod);  
  39.             *probed_mod = NULL;  
  40.             ret = -ENOENT;  
  41.         }  
  42.     }  
  43. out:  
  44.     preempt_enable();  
  45.     jump_label_unlock();  
  46.   
  47.     return ret;  
  48. }  
首先调用arch_check_ftrace_location确认是否探测地址已经被ftrace跟踪，若是且在开启了CONFIG_KPROBES_ON_FTRACE内核选项的情况下在该kprobe实例的flags上置位KPROBE_FLAG_FTRACE符号，表示本kprobe已使用ftrace。
然后上锁并竟用内核抢占，开始进入地址有效性检测流程，首先判断以下3个条件，必须全部满足：1、被探测地址在内核的地址段中；2、地址不在kprobe的黑名单之中；3、不在jump lable保留的地址空间中（内核jump lable特性使用？）。其中第一点比较好理解，函数实现如下：
[cpp] view plain copy
  1. int kernel_text_address(unsigned long addr)  
  2. {  
  3.     if (core_kernel_text(addr))  
  4.         return 1;  
  5.     if (is_module_text_address(addr))  
  6.         return 1;  
  7.     return is_ftrace_trampoline(addr);  
  8. }  

被探测的函数当然要在内核的text（_stext ~ _etext）段中，由于非内核启动时刻，不包括init text段；然后模块的text段和init text段也都可以，最后如果在ftrace动态分配的trampoline地址空间中也是满足的。

其中第二点中的blacklist黑名单指的是实现kprobes的关键代码路径，只有不在该黑名单中的函数才可以被探测：

[cpp] view plain copy
  1. bool __weak arch_within_kprobe_blacklist(unsigned long addr)  
  2. {  
  3.     /* The __kprobes marked functions and entry code must not be probed */  
  4.     return addr >= (unsigned long)__kprobes_text_start &&  
  5.            addr < (unsigned long)__kprobes_text_end;  
  6. }  
  7.   
  8. static bool within_kprobe_blacklist(unsigned long addr)  
  9. {  
  10.     struct kprobe_blacklist_entry *ent;  
  11.   
  12.     if (arch_within_kprobe_blacklist(addr))  
  13.         return true;  
  14.     /* 
  15.      * If there exists a kprobe_blacklist, verify and 
  16.      * fail any probe registration in the prohibited area 
  17.      */  
  18.     list_for_each_entry(ent, &kprobe_blacklist, list) {  
  19.         if (addr >= ent->start_addr && addr < ent->end_addr)  
  20.             return true;  
  21.     }  
  22.   
  23.     return false;  
  24. }  

主要包含两个方面，一是架构相关的kprobe关键代码路径，他们被保存在__kprobes_text_start~__kprobes_text_end段中，二是kprobe_blacklist链表，该链表前面在kprobe初始化过程中已经看到了。

首先__kprobes_text_start和__kprobes_text_end被定义在include/asm-generic/Vmlinux.lds.h中，使用宏__kprobes标记的函数被归入该.kprobes.text段：

[cpp] view plain copy
  1. #define KPROBES_TEXT                            \  
  2.         ALIGN_FUNCTION();                   \  
  3.         VMLINUX_SYMBOL(__kprobes_text_start) = .;       \  
  4.         *(.kprobes.text)                    \  
  5.         VMLINUX_SYMBOL(__kprobes_text_end) = .;  
[cpp] view plain copy
  1. #ifdef CONFIG_KPROBES  
  2. # define __kprobes  __attribute__((__section__(".kprobes.text")))  
简单的总结一下： 即使用宏NOKPROBE_SYMBOL和宏__kprobes标记的内核函数不可以被探测kprobe。

回到check_kprobe_address_safe函数中，若满足了以上三点，接下来判断被探测地址是否属于某一个内核模块的init_text段或core_text段：

[cpp] view plain copy
  1. struct module *__module_text_address(unsigned long addr)  
  2. {  
  3.     struct module *mod = __module_address(addr);  
  4.     if (mod) {  
  5.         /* Make sure it's within the text section. */  
  6.         if (!within(addr, mod->module_init, mod->init_text_size)  
  7.             && !within(addr, mod->module_core, mod->core_text_size))  
  8.             mod = NULL;  
  9.     }  
  10.     return mod;  
  11. }  
判断若属于某一个模块的话则增加这个模块的引用计数以防止模块被意外动态卸载，同时不允许在已经完成加载模块的init_text段中的函数注册kprobe（因为在模块加载完成后init_text段的内存已经被free掉了）。最后若模块获取成功，它将通过probed_mod参数返回给register_kprobe用于错误处理流程。

以上判断都通过之后重新打开内核抢占并解锁，回到register_kprobe函数继续注册流程。接下来尝试从全局hash表中查找是否之前已经为同一个被探测地址注册了kprobe探测点，若已注册则调用register_aggr_kprobe函数继续注册流程，该流程稍后再分析。现假设是初次注册，则调用prepare_kprobe函数，该函数会根据被探测地址是否已经被ftrace了而进入不同的流程，这里假设没有启用ftrace，则直接调用arch_prepare_kprobe函数进入架构相关的注册流程，先看一下x86架构的实现：

[cpp] view plain copy
  1. int arch_prepare_kprobe(struct kprobe *p)  
  2. {  
  3.     if (alternatives_text_reserved(p->addr, p->addr))  
  4.         return -EINVAL;  
  5.   
  6.     if (!can_probe((unsigned long)p->addr))  
  7.         return -EILSEQ;  
  8.     /* insn: must be on special executable page on x86. */  
  9.     p->ainsn.insn = get_insn_slot();  
  10.     if (!p->ainsn.insn)  
  11.         return -ENOMEM;  
  12.   
  13.     return arch_copy_kprobe(p);  
  14. }  
首先对于smp系统，被探测地址不能被用于smp-alternatives，非smp无此要求；然后判断该被探测地址的指令有效并调用get_insn_slot函数申请用于拷贝原始指令的指令slot内存空间，最后调用arch_copy_kprobe函数执行指令复制动作。
[cpp] view plain copy
  1. static int arch_copy_kprobe(struct kprobe *p)  
  2. {  
  3.     int ret;  
  4.   
  5.     /* Copy an instruction with recovering if other optprobe modifies it.*/  
  6.     ret = __copy_instruction(p->ainsn.insn, p->addr);  
  7.     if (!ret)  
  8.         return -EINVAL;  
  9.   
  10.     /* 
  11.      * __copy_instruction can modify the displacement of the instruction, 
  12.      * but it doesn't affect boostable check. 
  13.      */  
  14.     if (can_boost(p->ainsn.insn))  
  15.         p->ainsn.boostable = 0;  
  16.     else  
  17.         p->ainsn.boostable = -1;  
  18.   
  19.     /* Check whether the instruction modifies Interrupt Flag or not */  
  20.     p->ainsn.if_modifier = is_IF_modifier(p->ainsn.insn);  
  21.   
  22.     /* Also, displacement change doesn't affect the first byte */  
  23.     p->opcode = p->ainsn.insn[0];  
  24.   
  25.     return 0;  
  26. }  
函数首先调用__copy_instruction将kprobe->addr被探测地址的指令拷贝到kprobe->ainsn.insn保存起来（可能会对指令做适当的修改），然后初始化kprobe->ainsn结构体，最后将指令的第一个字节保存到kprobe->opcode字段中（x86架构的kprobe_opcode_t是u8类型的）。
再来看一下arm架构的实现方式（已去除CONFIG_THUMB2_KERNEL相关部分的代码）：
[cpp] view plain copy
  1. int __kprobes arch_prepare_kprobe(struct kprobe *p)  
  2. {  
  3.     kprobe_opcode_t insn;  
  4.     kprobe_opcode_t tmp_insn[MAX_INSN_SIZE];  
  5.     unsigned long addr = (unsigned long)p->addr;  
  6.     bool thumb;  
  7.     kprobe_decode_insn_t *decode_insn;  
  8.     const union decode_action *actions;  
  9.     int is;  
  10.     const struct decode_checker **checkers;  
  11.   
  12.     if (in_exception_text(addr))  
  13.         return -EINVAL;  
  14.   
  15. #ifdef CONFIG_THUMB2_KERNEL  
  16.     ......  
  17. #else /* !CONFIG_THUMB2_KERNEL */  
  18.     thumb = false;  
  19.     if (addr & 0x3)  
  20.         return -EINVAL;  
  21.     insn = __mem_to_opcode_arm(*p->addr);  
  22.     decode_insn = arm_probes_decode_insn;  
  23.     actions = kprobes_arm_actions;  
  24.     checkers = kprobes_arm_checkers;  
  25. #endif  
  26.   
  27.     p->opcode = insn;  
  28.     p->ainsn.insn = tmp_insn;  
  29.   
  30.     switch ((*decode_insn)(insn, &p->ainsn, true, actions, checkers)) {  
  31.     case INSN_REJECTED: /* not supported */  
  32.         return -EINVAL;  
  33.   
  34.     case INSN_GOOD:     /* instruction uses slot */  
  35.         p->ainsn.insn = get_insn_slot();  
  36.         if (!p->ainsn.insn)  
  37.             return -ENOMEM;  
  38.         for (is = 0; is < MAX_INSN_SIZE; ++is)  
  39.             p->ainsn.insn[is] = tmp_insn[is];  
  40.         flush_insns(p->ainsn.insn,  
  41.                 sizeof(p->ainsn.insn[0]) * MAX_INSN_SIZE);  
  42.         p->ainsn.insn_fn = (probes_insn_fn_t *)  
  43.                     ((uintptr_t)p->ainsn.insn | thumb);  
  44.         break;  
  45.   
  46.     case INSN_GOOD_NO_SLOT: /* instruction doesn't need insn slot */  
  47.         p->ainsn.insn = NULL;  
  48.         break;  
  49.     }  
  50.   
  51.     /* 
  52.      * Never instrument insn like 'str r0, [sp, +/-r1]'. Also, insn likes 
  53.      * 'str r0, [sp, #-68]' should also be prohibited. 
  54.      * See __und_svc. 
  55.      */  
  56.     if ((p->ainsn.stack_space < 0) ||  
  57.             (p->ainsn.stack_space > MAX_STACK_SIZE))  
  58.         return -EINVAL;  
  59.   
  60.     return 0;  
  61. }  
首先检测被探测地址不能在异常代码段中并且地址必须是4字节对齐的，随后取出被探测点的指令保存在kprobe->opcode中，并调用arm_probes_decode_insn函数来判断被探测的指令是什么类型的：
[cpp] view plain copy
  1. /* Return: 
  2.  *   INSN_REJECTED     If instruction is one not allowed to kprobe, 
  3.  *   INSN_GOOD         If instruction is supported and uses instruction slot, 
  4.  *   INSN_GOOD_NO_SLOT If instruction is supported but doesn't use its slot. 
  5.  * 
  6.  * For instructions we don't want to kprobe (INSN_REJECTED return result): 
  7.  *   These are generally ones that modify the processor state making 
  8.  *   them "hard" to simulate such as switches processor modes or 
  9.  *   make accesses in alternate modes.  Any of these could be simulated 
  10.  *   if the work was put into it, but low return considering they 
  11.  *   should also be very rare. 
  12.  */  
  13. enum probes_insn __kprobes  
  14. arm_probes_decode_insn(probes_opcode_t insn, struct arch_probes_insn *asi,  
  15.                bool emulate, const union decode_action *actions,  
  16.                const struct decode_checker *checkers[])  
  17. {  
  18.     asi->insn_singlestep = arm_singlestep;  
  19.     asi->insn_check_cc = probes_condition_checks[insn>>28];  
  20.     return probes_decode_insn(insn, asi, probes_decode_arm_table, false,  
  21.                   emulate, actions, checkers);  
  22. }  

该arm_probes_decode_insn调用流程会对kprobe->ainsn结构进行初始化（该结构架构相关），其中函数指针insn_singlestep初始化为arm_singlestep，它用于kprobe触发后的单步执行，而函数insn_check_cc初始化为probes_condition_checks[insn>>28]，它是一个函数指针数组，以指令的高4位为索引，用于kprobe触发后进行条件异常检测。

[cpp] view plain copy
  1. probes_check_cc * const probes_condition_checks[16] = {  
  2.     &__check_eq, &__check_ne, &__check_cs, &__check_cc,  
  3.     &__check_mi, &__check_pl, &__check_vs, &__check_vc,  
  4.     &__check_hi, &__check_ls, &__check_ge, &__check_lt,  
  5.     &__check_gt, &__check_le, &__check_al, &__check_al  
  6. };  

现以do_fork函数为例，来看一下这里的insn_check_cc函数指针初始化为那个函数了：

反汇编vmlinux后找到do_fork，对应的入口地址为0xc0022798，汇编指令为mov，机器码为e1a0c00d，计算后值为0xe=15，因此选中的条件异常检测处理函数为__check_al；

[cpp] view plain copy
  1. c0022798 :  
  2. do_fork():  
  3. c0022798:       e1a0c00d        mov     ip, sp  

如果用户探测的并不是函数的入口地址，而是函数内部的某一条指令，则可能会选中其他的检测函数，例如movne指令选中的就是__check_ne，moveq指令选中的就是__check_eq等等。

回到arm_probes_decode_insn函数中，然后调用probes_decode_insn函数判断指令的类型并初始化单步执行函数指针insn_handler，最后返回INSN_REJECTED、INSN_GOOD和INSN_GOOD_NO_SLOT这三种类型（如果是INSN_GOOD还会拷贝指令填充ainsn.insn字段）。该函数的注释中对其描述的已经比较详细了，对于诸如某些会修改处理器工作状态的指令会返回INSN_REJECTED表示不支持，另外INSN_GOOD是需要slot的指令，INSN_GOOD_NO_SLOT是不需要slot的指令。

回到arch_prepare_kprobe函数中，会对返回的指令类型做不同的处理，若是INSN_GOOD类型则同x86类似，调用get_insn_slot申请内存空间并将前面存放在tmp_insn中的指令拷贝到kprobe->ainsn.insn中，然后flush icache。

如此被探测点指令就被拷贝保存起来了。架构相关的初始化完成以后，接下来register_kprobe函数初始化kprobe的hlist字段并将它添加到全局的hash表中。然后判断如果kprobes_all_disarmed为false并且kprobe没有被disable（在kprobe的初始化函数中该kprobes_all_disarmed值默认为false），则调用arm_kprobe函数，它会把触发trap的指令写到被探测点处替换原始指令。

[cpp] view plain copy
  1. static void arm_kprobe(struct kprobe *kp)  
  2. {  
  3.     if (unlikely(kprobe_ftrace(kp))) {  
  4.         arm_kprobe_ftrace(kp);  
  5.         return;  
  6.     }  
  7.     /* 
  8.      * Here, since __arm_kprobe() doesn't use stop_machine(), 
  9.      * this doesn't cause deadlock on text_mutex. So, we don't 
  10.      * need get_online_cpus(). 
  11.      */  
  12.     mutex_lock(&text_mutex);  
  13.     __arm_kprobe(kp);  
  14.     mutex_unlock(&text_mutex);  
  15. }  
这里假设不适用ftrace和optimize kprobe特性，将直接调用架构相关的函数arch_arm_kprobe，其中x86的实现如下：
[cpp] view plain copy
  1. void arch_arm_kprobe(struct kprobe *p)  
  2. {  
  3.     text_poke(p->addr, ((unsigned char []){BREAKPOINT_INSTRUCTION}), 1);  
  4. }  
直接调用text_poke函数将addr地址处的指令替换为BREAKPOINT_INSTRUCTION指令（机器码是0xCC），当正常执行流程执行到这条指令后就会触发int3中断，进而进入探测回调流程。再看一下arm的实现流程：
[cpp] view plain copy
  1. void __kprobes arch_arm_kprobe(struct kprobe *p)  
  2. {  
  3.     unsigned int brkp;  
  4.     void *addr;  
  5.   
  6.     if (IS_ENABLED(CONFIG_THUMB2_KERNEL)) {  
  7.         ......  
  8.     } else {  
  9.         kprobe_opcode_t insn = p->opcode;  
  10.   
  11.         addr = p->addr;  
  12.         brkp = KPROBE_ARM_BREAKPOINT_INSTRUCTION;  
  13.   
  14.         if (insn >= 0xe0000000)  
  15.             brkp |= 0xe0000000;  /* Unconditional instruction */  
  16.         else  
  17.             brkp |= insn & 0xf0000000;  /* Copy condition from insn */  
  18.     }  
  19.   
  20.     patch_text(addr, brkp);  
  21. }   

arm架构的实现中替换的指令为KPROBE_ARM_BREAKPOINT_INSTRUCTION（机器码是0x07f001f8），然后还会根据被替换指令做一定的调整，最后调用patch_text函数执行替换动作。继续以kprobe_example例程中的do_fork函数为例，从前文中反汇编可知，地址0xc0022798处的“mov     ip, sp”指令被替换KPROBE_ARM_BREAKPOINT_INSTRUCTION指令，可从pre_handler回调函数中打印的地址得到印证：

<6>[   57.386132] [do_fork] pre_handler: p->addr = 0xc0022798, pc = 0xc0022798, cpsr = 0x80000013
<6>[   57.386167] [do_fork] post_handler: p->addr = 0xc0022798, cpsr = 0x80000013

前文中看到KPROBE_ARM_BREAKPOINT_INSTRUCTION指令在init_kprobes函数的执行流程中已经为它注册了一个异常处理函数kprobe_trap_handler，因此当正常执行流程执行到KPROBE_ARM_BREAKPOINT_INSTRUCTION指令后将触发异常，进而调用kprobe_trap_handler开始回调流程。

至此kprobe的注册流程分析完毕，再回头分析对一个已经被注册过kprobe的探测点注册新的kprobe的执行流程，即register_aggr_kprobe函数：

[cpp] view plain copy
  1. /* 
  2.  * This is the second or subsequent kprobe at the address - handle 
  3.  * the intricacies 
  4.  */  
  5. static int register_aggr_kprobe(struct kprobe *orig_p, struct kprobe *p)  
  6. {  
  7.     int ret = 0;  
  8.     struct kprobe *ap = orig_p;  
  9.   
  10.     /* For preparing optimization, jump_label_text_reserved() is called */  
  11.     jump_label_lock();  
  12.     /* 
  13.      * Get online CPUs to avoid text_mutex deadlock.with stop machine, 
  14.      * which is invoked by unoptimize_kprobe() in add_new_kprobe() 
  15.      */  
  16.     get_online_cpus();  
  17.     mutex_lock(&text_mutex);  
  18.   
  19.     if (!kprobe_aggrprobe(orig_p)) {  
  20.         /* If orig_p is not an aggr_kprobe, create new aggr_kprobe. */  
  21.         ap = alloc_aggr_kprobe(orig_p);  
  22.         if (!ap) {  
  23.             ret = -ENOMEM;  
  24.             goto out;  
  25.         }  
  26.         init_aggr_kprobe(ap, orig_p);  
  27.     } else if (kprobe_unused(ap))  
  28.         /* This probe is going to die. Rescue it */  
  29.         reuse_unused_kprobe(ap);  
  30.   
  31.     if (kprobe_gone(ap)) {  
  32.         /* 
  33.          * Attempting to insert new probe at the same location that 
  34.          * had a probe in the module vaddr area which already 
  35.          * freed. So, the instruction slot has already been 
  36.          * released. We need a new slot for the new probe. 
  37.          */  
  38.         ret = arch_prepare_kprobe(ap);  
  39.         if (ret)  
  40.             /* 
  41.              * Even if fail to allocate new slot, don't need to 
  42.              * free aggr_probe. It will be used next time, or 
  43.              * freed by unregister_kprobe. 
  44.              */  
  45.             goto out;  
  46.   
  47.         /* Prepare optimized instructions if possible. */  
  48.         prepare_optimized_kprobe(ap);  
  49.   
  50.         /* 
  51.          * Clear gone flag to prevent allocating new slot again, and 
  52.          * set disabled flag because it is not armed yet. 
  53.          */  
  54.         ap->flags = (ap->flags & ~KPROBE_FLAG_GONE)  
  55.                 | KPROBE_FLAG_DISABLED;  
  56.     }  
  57.   
  58.     /* Copy ap's insn slot to p */  
  59.     copy_kprobe(ap, p);  
  60.     ret = add_new_kprobe(ap, p);  
  61.   
  62. out:  
  63.     mutex_unlock(&text_mutex);  
  64.     put_online_cpus();  
  65.     jump_label_unlock();  
  66.   
  67.     if (ret == 0 && kprobe_disabled(ap) && !kprobe_disabled(p)) {  
  68.         ap->flags &= ~KPROBE_FLAG_DISABLED;  
  69.         if (!kprobes_all_disarmed)  
  70.             /* Arm the breakpoint again. */  
  71.             arm_kprobe(ap);  
  72.     }  
  73.     return ret;  
  74. }  
在前文中看到，该函数会在对同一个被探测地址注册多个kprobe实例时会被调用到，该函数会引入一个kprobe aggregator的概念，即由一个统一的kprobe实例接管所有注册到该地址的kprobe。这个函数的注释非常详细，并不难理解，来简单分析一下：
函数的第一个入参orig_p是在全局hash表中找到的已经注册的kprobe实例，第二个入参是本次需要注册的kprobe实例。首先在完成了必要的上锁操作后就调用kprobe_aggrprobe函数检查orig_p是否是一个aggregator。
[cpp] view plain copy
  1. /* Return true if the kprobe is an aggregator */  
  2. static inline int kprobe_aggrprobe(struct kprobe *p)  
  3. {  
  4.     return p->pre_handler == aggr_pre_handler;  
  5. }  
它通过kprobe的pre_handler回调判断，如果是aggregator则它的pre_handler回调函数会被替换成aggr_pre_handler函数。一般对于第二次注册kprobe的情况显然是不会满足条件的，会调用alloc_aggr_kprobe函数创建一个，对于没有开启CONFIG_OPTPROBES选项的情况，alloc_aggr_kprobe仅仅是分配了一块内存空间，然后调用init_aggr_kprobe函数初始化这个aggr kprobe。
[cpp] view plain copy
  1. /* 
  2.  * Fill in the required fields of the "manager kprobe". Replace the 
  3.  * earlier kprobe in the hlist with the manager kprobe 
  4.  */  
  5. static void init_aggr_kprobe(struct kprobe *ap, struct kprobe *p)  
  6. {  
  7.     /* Copy p's insn slot to ap */  
  8.     copy_kprobe(p, ap);  
  9.     flush_insn_slot(ap);  
  10.     ap->addr = p->addr;  
  11.     ap->flags = p->flags & ~KPROBE_FLAG_OPTIMIZED;  
  12.     ap->pre_handler = aggr_pre_handler;  
  13.     ap->fault_handler = aggr_fault_handler;  
  14.     /* We don't care the kprobe which has gone. */  
  15.     if (p->post_handler && !kprobe_gone(p))  
  16.         ap->post_handler = aggr_post_handler;  
  17.     if (p->break_handler && !kprobe_gone(p))  
  18.         ap->break_handler = aggr_break_handler;  
  19.   
  20.     INIT_LIST_HEAD(&ap->list);  
  21.     INIT_HLIST_NODE(&ap->hlist);  
  22.   
  23.     list_add_rcu(&p->list, &ap->list);  
  24.     hlist_replace_rcu(&p->hlist, &ap->hlist);  
  25. }  
可以看到，这个aggr kprobe中的各个字段基本就是从orig_p中拷贝过来的，包括opcode和ainsn这两个备份指令的字段以及addr和flags字段，但是其中的4个回调函数会被初始化为aggr kprobe所特有的addr_xxx_handler，这几个函数后面会具体分析。接下来函数会初始化aggr kprobe的两个链表头，然后将自己添加到链表中去，并替换掉orig_p。

回到register_aggr_kprobe函数中，如果本次是第二次以上向同一地址注册kprobe实例，则此时的orig_p已经是aggr kprobe了，则会调用kprobe_unused函数判断该kprobe是否为被使用，若是则调用reuse_unused_kprobe函数重新启用，但是对于没有开启CONFIG_OPTPROBES选项的情况，逻辑上是不存在这种情况的，因此reuse_unused_kprobe函数的实现仅仅是一段打印后就立即触发BUG_ON。

[cpp] view plain copy
  1. /* There should be no unused kprobes can be reused without optimization */  
  2. static void reuse_unused_kprobe(struct kprobe *ap)  
  3. {  
  4.     printk(KERN_ERR "Error: There should be no unused kprobe here.\n");  
  5.     BUG_ON(kprobe_unused(ap));  
  6. }  

继续往下分析，下面来讨论aggr kprobe被kill掉的情况，显然只有在第三次及以上注册同一地址可能会出现这样的情况。针对这一种情况，这里同初次注册kprobe的调用流程类似，首先调用arch_prepare_kprobe做架构相关初始化，保存被探测地址的机器指令，然后调用prepare_optimized_kprobe启用optimized_kprobe，最后清除KPROBE_FLAG_GONE的标记。

接下来调用再次copy_kprobe将aggr kprobe中保存的指令opcode和ainsn字段拷贝到本次要注册的kprobe的对应字段中，然后调用add_new_kprobe函数将新注册的kprobe链入到aggr kprobe的list链表中：

[cpp] view plain copy
  1. /* 
  2. * Add the new probe to ap->list. Fail if this is the 
  3. * second jprobe at the address - two jprobes can't coexist 
  4. */  
  5. static int add_new_kprobe(struct kprobe *ap, struct kprobe *p)  
  6. {  
  7.     BUG_ON(kprobe_gone(ap) || kprobe_gone(p));  
  8.   
  9.     if (p->break_handler || p->post_handler)  
  10.         unoptimize_kprobe(ap, true);    /* Fall back to normal kprobe */  
  11.   
  12.     if (p->break_handler) {  
  13.         if (ap->break_handler)  
  14.             return -EEXIST;  
  15.         list_add_tail_rcu(&p->list, &ap->list);  
  16.         ap->break_handler = aggr_break_handler;  
  17.     } else  
  18.         list_add_rcu(&p->list, &ap->list);  
  19.     if (p->post_handler && !ap->post_handler)  
  20.         ap->post_handler = aggr_post_handler;  
  21.   
  22.     return 0;  
  23. }  
注意最主要的就是add list，只是如果新注册的kprobe设定了break_handler回调函数，会将其插入链表的末尾并为aggr kprobe设定break handler回调函数aggr_break_handler；与此同时若新注册的kprobe设定了post_handler，也同样为aggr kprobe设定post handler回调函数aggr_post_handler。

回到register_aggr_kprobe函数，在out标号处继续执行，下面会进入if条件判断，启用aggr kprobe，然后调用前文中分析过的arm_kprobe函数替换被探测地址的机器指令为BREAKPOINT_INSTRUCTION指令。

至此整个kprobe注册流程分析结束，下面来分析以上注册的探测回调函数是如何被执行的以及被探测指令是如何被单步执行的。


3、触发kprobe探测和回调

前文中，从register_kprobe函数注册kprobe的流程已经看到，用户指定的被探测函数入口地址处的指令已经被替换成架构相关的BREAKPOINT_INSTRUCTION指令，若是正常的代码流程执行到该指令，将会触发异常，进入架构相关的异常处理函数，kprobe注册的回调函数及被探测函数的单步执行流程均在该流程中执行。由于不同架构实现存在差别，下面分别来分析，首先先分析arm架构的执行流程：

3.1、arm架构实现

前文中已经分析了内核已经为KPROBE_ARM_BREAKPOINT_INSTRUCTION指令注册了异常处理回调函数kprobe_trap_handler，因此在执行这条指令时会触发以下调用流程：__und_svc->__und_svc_fault->__und_fault->do_undefinstr()->call_undef_hook()：

[cpp] view plain copy
  1. static int __kprobes kprobe_trap_handler(struct pt_regs *regs, unsigned int instr)  
  2. {  
  3.     unsigned long flags;  
  4.     local_irq_save(flags);  
  5.     kprobe_handler(regs);  
  6.     local_irq_restore(flags);  
  7.     return 0;  
  8. }  
call_undef_hook()调用未定义指令的回调函数，对于KPROBE_ARM_BREAKPOINT_INSTRUCTION指令即调用到kprobe_trap_handler函数，其中入参struct pt_regs *regs保存的时执行异常指令时的寄存器信息，同时该函数在处理kprobe的流程时会禁用掉本地CPU的中断。

kprobe_handler函数的实现比较长，分段来看：

[cpp] view plain copy
  1. /* 
  2.  * Called with IRQs disabled. IRQs must remain disabled from that point 
  3.  * all the way until processing this kprobe is complete.  The current 
  4.  * kprobes implementation cannot process more than one nested level of 
  5.  * kprobe, and that level is reserved for user kprobe handlers, so we can't 
  6.  * risk encountering a new kprobe in an interrupt handler. 
  7.  */  
  8. void __kprobes kprobe_handler(struct pt_regs *regs)  
  9. {  
  10.     struct kprobe *p, *cur;  
  11.     struct kprobe_ctlblk *kcb;  
  12.   
  13.     kcb = get_kprobe_ctlblk();  
  14.     cur = kprobe_running();  
  15.   
  16. #ifdef CONFIG_THUMB2_KERNEL  
  17.     ......  
  18. #else /* ! CONFIG_THUMB2_KERNEL */  
  19.     p = get_kprobe((kprobe_opcode_t *)regs->ARM_pc);  
  20. #endif  
注释中说明了当前arm架构的kprobe实现不支持在中断中多层kprobe重入，因此为了防止在处理一个kprobe期间由于中断可能会导致多次触发kprobe的情况，所以需要禁用中断。函数首先调用get_kprobe_ctlblk函数获取本cpu的per_cpu结构体变量kprobe_ctlblk，该结构体是架构相关的，arm的定义如下：
[cpp] view plain copy
  1. /* per-cpu kprobe control block */  
  2. struct kprobe_ctlblk {  
  3.     unsigned int kprobe_status;  
  4.     struct prev_kprobe prev_kprobe;  
  5.     struct pt_regs jprobe_saved_regs;  
  6.     char jprobes_stack[MAX_STACK_SIZE];  
  7. };  
其中保存了kprobe的一些状态信息以及jpboe用到的字段，目前需要关注的是其中的kprobe_status和prev_kprobe字段，其中kprobe_status代表了当前kprobe的处理状态，一共包括以下几种：
[cpp] view plain copy
  1. #define KPROBE_HIT_ACTIVE   0x00000001      //开始处理kprobe  
  2. #define KPROBE_HIT_SS       0x00000002      //kprobe单步执行阶段  
  3. #define KPROBE_REENTER      0x00000004      //重复触发kprobe  
  4. #define KPROBE_HIT_SSDONE   0x00000008      //kprobe单步执行阶段结束  

而prev_kprobe则是用于在kprobe重入情况下保存当前正在处理的kprobe实例和状态的。内核为每个cpu都定义了一个该类型全局变量。然后调用kprobe_running函数获取当前cpu上正在处理的kprobe：

[cpp] view plain copy
  1. /* kprobe_running() will just return the current_kprobe on this CPU */  
  2. static inline struct kprobe *kprobe_running(void)  
  3. {  
  4.     return (__this_cpu_read(current_kprobe));  
  5. }  
这里的current_kprobe也是一个per_cpu变量，其中保存了当前cpu正在处理的kprobe实例，若没有正在处理的则为NULL。下面调用get_kprobe函数获取本次要处理的kprobe，入参是regs->ARM_pc，即触发异常指令所在的地址，也就是被探测点的地址，利用它就可以在全局hash表中找到注册的kprobe实例了。接下来根据cur和p的存在情况进行多分支处理：

1、p和cur的kprobe实例同时存在

[cpp] view plain copy
  1. /* Kprobe is pending, so we're recursing. */  
  2. switch (kcb->kprobe_status) {  
  3. case KPROBE_HIT_ACTIVE:  
  4. case KPROBE_HIT_SSDONE:  
  5.     /* A pre- or post-handler probe got us here. */  
  6.     kprobes_inc_nmissed_count(p);  
  7.     save_previous_kprobe(kcb);  
  8.     set_current_kprobe(p);  
  9.     kcb->kprobe_status = KPROBE_REENTER;  
  10.     singlestep(p, regs, kcb);  
  11.     restore_previous_kprobe(kcb);  
  12.     break;  
  13. default:  
  14.     /* impossible cases */  
  15.     BUG();  
  16. }  
这种情况属于kprobe重入的情况，即在运行kprobe回调函数或单步执行被探测指令时又一次触发了kprobe。对于重入，目前流程只能处理在前一kprobe执行回调函数时引发的kprobe重入，对于在单步执行阶段引发的重入就直接报BUG。具体的处理流程为：首先调用kprobes_inc_nmissed_count递增当前要处理kprobe的nmissed值（如果是aggr kprobe则会遍历链表将注册到同地址的所有kprobe的nmissed值都加1）；然后调用save_previous_kprobe函数将当前时刻已经在处理的kprobe（cur）及状态保存到kcb->prev_kprobe字段中去；
[cpp] view plain copy
  1. static void __kprobes save_previous_kprobe(struct kprobe_ctlblk *kcb)  
  2. {  
  3.     kcb->prev_kprobe.kp = kprobe_running();  
  4.     kcb->prev_kprobe.status = kcb->kprobe_status;  
  5. }  
然后调用set_current_kprobe函数将本次需要处理的kprobe（p）设置到current_kprobe的per_cpu变量中去，并且更新kprobe_status状态为KPROBE_REENTER，表示存在重入情况；接下来调用singlestep函数启动单步执行，这个函数稍后再看；最后调用restore_previous_kprobe函数恢复前面所保存的kprobe。
[cpp] view plain copy
  1. static void __kprobes save_previous_kprobe(struct kprobe_ctlblk *kcb)  
  2. {  
  3.     kcb->prev_kprobe.kp = kprobe_running();  
  4.     kcb->prev_kprobe.status = kcb->kprobe_status;  
  5. }  

注意，以上重入的处理流程仅仅是单步执行了被探测的函数，并不会调用kprobe的pre_handle回调函数（递增nmissed字段的原因就在此），因此用户并不会感知到kprobe被实际触发了。

2、p存在但cur不存在

[cpp] view plain copy
  1. } else if (p->ainsn.insn_check_cc(regs->ARM_cpsr)) {  
  2.     /* Probe hit and conditional execution check ok. */  
  3.     set_current_kprobe(p);  
  4.     kcb->kprobe_status = KPROBE_HIT_ACTIVE;  
  5.   
  6.     /* 
  7.      * If we have no pre-handler or it returned 0, we 
  8.      * continue with normal processing.  If we have a 
  9.      * pre-handler and it returned non-zero, it prepped 
  10.      * for calling the break_handler below on re-entry, 
  11.      * so get out doing nothing more here. 
  12.      */  
  13.     if (!p->pre_handler || !p->pre_handler(p, regs)) {  
  14.         kcb->kprobe_status = KPROBE_HIT_SS;  
  15.         singlestep(p, regs, kcb);  
  16.         if (p->post_handler) {  
  17.             kcb->kprobe_status = KPROBE_HIT_SSDONE;  
  18.             p->post_handler(p, regs, 0);  
  19.         }  
  20.         reset_current_kprobe();  
  21.     }  
  22. } else {  
  23.     /* 
  24.      * Probe hit but conditional execution check failed, 
  25.      * so just skip the instruction and continue as if 
  26.      * nothing had happened. 
  27.      */  
  28.     singlestep_skip(p, regs);  
  29. }  

这种情况就是最为一般的情况，即当前kprobe是首次触发，前面并没有其他的kprobe流程正在处理。这里会首先调用p->ainsn.insn_check_cc注册函数来进行条件异常检测，这个函数在前文注册kprobe的流程中已经看到根据不同的被探测指令被注册成不同的函数了，入参是触发异常时的cpsr程序状态寄存器值。

对于前文中看到的do_fork函数入口汇编指令mov设置的__check_al检测函数来说，它将永远返回true，而movne指令的__check_ne检测函数则会对cpsr进行判断：

[cpp] view plain copy
  1. static unsigned long __kprobes __check_ne(unsigned long cpsr)  
  2. {  
  3.     return (~cpsr) & PSR_Z_BIT;  
  4. }  

（1）如果条件异常检测通过，那也同样调用set_current_kprobe函数设置当前正在处理的kprobe并更新kprobe状态标识为KPROBE_HIT_ACTIVE，表明开始处理该kprobe。接下来就到关键的回调和单步执行流程了，首先判断kprobe的pre_handler函数是否被注册，在注册的情况下调用它。对于单kprobe注册的情况很简单了，直接调用注册函数即可（这样前面kprobe_example中handler_pre函数就在此调用），但是对于前文中分析的多kprobe注册的情况（aggr kprobe），则会调用到aggr_pre_handler函数：

[cpp] view plain copy
  1. /* 
  2.  * Aggregate handlers for multiple kprobes support - these handlers 
  3.  * take care of invoking the individual kprobe handlers on p->list 
  4.  */  
  5. static int aggr_pre_handler(struct kprobe *p, struct pt_regs *regs)  
  6. {  
  7.     struct kprobe *kp;  
  8.   
  9.     list_for_each_entry_rcu(kp, &p->list, list) {  
  10.         if (kp->pre_handler && likely(!kprobe_disabled(kp))) {  
  11.             set_kprobe_instance(kp);  
  12.             if (kp->pre_handler(kp, regs))  
  13.                 return 1;  
  14.         }  
  15.         reset_kprobe_instance();  
  16.     }  
  17.     return 0;  
  18. }  
  19. NOKPROBE_SYMBOL(aggr_pre_handler);  
该函数的功能很直观，即遍历aggr_kprobe->list链表中的各个同注册地址的kprobe实例，然后调用它们自己的pre_handler回调函数，这里的aggr_kprobe仅仅起到了一个管理分配的作用。其中set_kprobe_instance和reset_kprobe_instance函数的作用是设置和恢复kprobe_instance这个per_cpu变量，这个变量在aggr_fault_handler和aggr_break_handler回调函数中会用到，应为发生异常时，需要定位到当前正在处理哪一个kprobe。
[cpp] view plain copy
  1. /* We have preemption disabled.. so it is safe to use __ versions */  
  2. static inline void set_kprobe_instance(struct kprobe *kp)  
  3. {  
  4.     __this_cpu_write(kprobe_instance, kp);  
  5. }  
  6.   
  7. static inline void reset_kprobe_instance(void)  
  8. {  
  9.     __this_cpu_write(kprobe_instance, NULL);  
  10. }  
回到kprobe_handler函数继续往下分析，如果pre_handler执行成功或者不存在pre_handler回调函数则将kprobe当前处理状态设置为KPROBE_HIT_SS，表示开始进入单步执行阶段。随后 调用singlestep函数单步执行”原始被探测指令“，完毕后继续判断post_handler回调函数是否存在，若存在则设置当前状态为KPROBE_HIT_SSDONE，表示单步执行阶段执行结束，然后 调用post_handler回调函数（前文kprobe_example总的handler_post就在此调用）。post_handler同pre_handler一样，对与aggr kprobe会调用aggr_post_handler函数，由于实现类似，这里就不再赘述了。在执行完所有的回调后，最后调用reset_current_kprobe函数恢复current_kprobe变量。

这里可能会存在这样的疑问，为什么kcb->kprobe_status = KPROBE_HIT_SSDONE;这条状态赋值语句会放在条件判断内部，而不是在单步执行完以后？其实对于当前的上下文逻辑来看效果是一样的，因为若没有注册post_handler，就会立即执行reset_current_kprobe函数解除kprobe的绑定，因此不会对逻辑产生影响。

（2）如果条件异常检测不通过则调用singlestep_skip函数跳过当前的指令，继续执行后面的指令，就像什么都没有发生过一样

[cpp] view plain copy
  1. static void __kprobes  
  2. singlestep_skip(struct kprobe *p, struct pt_regs *regs)  
  3. {  
  4. #ifdef CONFIG_THUMB2_KERNEL  
  5.     ......  
  6. #else  
  7.     regs->ARM_pc += 4;  
  8. #endif  
  9. }  
该函数仅仅修改了regs结构中的PC值，在kprobe处理结束后将从被探测指令之后的指令继续执行。 这里就有一个疑问，如果不执行被探测点的原始指令，直接执行之后的指令难道不会出问题吗？

3、p不存在但cur存在

[cpp] view plain copy
  1. } else if (cur) {  
  2.     /* We probably hit a jprobe.  Call its break handler. */  
  3.     if (cur->break_handler && cur->break_handler(cur, regs)) {  
  4.         kcb->kprobe_status = KPROBE_HIT_SS;  
  5.         singlestep(cur, regs, kcb);  
  6.         if (cur->post_handler) {  
  7.             kcb->kprobe_status = KPROBE_HIT_SSDONE;  
  8.             cur->post_handler(cur, regs, 0);  
  9.         }  
  10.     }  
  11.     reset_current_kprobe();  
这种情况一般用于jprobe实现，函数调用cur kprobe的break_handler回调函数且在break_handler返回非0的情况下启动单步执行和执行post_handler回调，最后一样调用reset_current_kprobe函数解除cur kprobe绑定。该流程先不做详细推演分析，后面分析jprobe实现时再细细分析。

4、p和cur都不存在

[cpp] view plain copy
  1. } else {  
  2.     /* 
  3.      * The probe was removed and a race is in progress. 
  4.      * There is nothing we can do about it.  Let's restart 
  5.      * the instruction.  By the time we can restart, the 
  6.      * real instruction will be there. 
  7.      */  
  8. }  
这种情况表示当前kprobe已经被注销了，但是可能在注销的过程中（注销的过程并不是原子操作）可能被其他执行流程抢占进而触发该kprobe，对于这种情况什么都不需要做，直接返回即可。

至此arm架构的kprobe触发及处理整体流程就分析完了。下面分析x86_64架构的实现，总体大同小异，其中的相同之处就不再分析了。

3.2、x86_64架构实现

[cpp] view plain copy
  1. /* May run on IST stack. */  
  2. dotraplinkage void notrace do_int3(struct pt_regs *regs, long error_code)  
  3. {  
  4.     ......  
  5.   
  6. #ifdef CONFIG_KPROBES  
  7.     if (kprobe_int3_handler(regs))  
  8.         goto exit;  
  9. #endif  
  10.     ......  
  11. }  
  12. NOKPROBE_SYMBOL(do_int3);  
x86_64架构下，执行到前文中替换的BREAKPOINT_INSTRUCTION指令后将触发INT3中断，进而调用到do_int3函数。do_init3函数做的事情比较多，但是和kprobe相关的仅代码中列出的这1处，下面来看kprobe_int3_handler函数，这个函数同arm结构的kprobe_handler函数很像，依然分段来分析：
[cpp] view plain copy
  1. /* 
  2.  * Interrupts are disabled on entry as trap3 is an interrupt gate and they 
  3.  * remain disabled throughout this function. 
  4.  */  
  5. int kprobe_int3_handler(struct pt_regs *regs)  
  6. {  
  7.     kprobe_opcode_t *addr;  
  8.     struct kprobe *p;  
  9.     struct kprobe_ctlblk *kcb;  
  10.   
  11.     if (user_mode(regs))  
  12.         return 0;  
  13.   
  14.     addr = (kprobe_opcode_t *)(regs->ip - sizeof(kprobe_opcode_t));  
  15.     /* 
  16.      * We don't want to be preempted for the entire 
  17.      * duration of kprobe processing. We conditionally 
  18.      * re-enable preemption at the end of this function, 
  19.      * and also in reenter_kprobe() and setup_singlestep(). 
  20.      */  
  21.     preempt_disable();  
  22.   
  23.     kcb = get_kprobe_ctlblk();  
  24.     p = get_kprobe(addr);  

本地中断在处理kprobe期间依然被禁止，同时调用user_mode函数确保本处理函数处理的int3中断是在内核态执行流程期间被触发的（因为kprobe不会从用户态触发），这里之所以要做这么一个判断是因为同arm定义特殊未处理指令回调函数不同，这里的do_int3要通用的多，并不是单独为kprobe所设计的。然后获取被探测指令的地址保存到addr中（对于int3中断，其被Intel定义为trap，那么异常发生时EIP寄存器内指向的为异常指令的后一条指令），同时会禁用内核抢占，注释中说明在reenter_kprobe和单步执行时会有选择的重新开启内核抢占。接下来下面同arm一样获取当前cpu的kprobe_ctlblk控制结构体和本次要处理的kprobe实例p，然后根据不同的情况进行不同分支的处理。在继续分析前先来看一下x86_64架构kprobe_ctlblk结构体的定义

[cpp] view plain copy
  1. /* per-cpu kprobe control block */  
  2. struct kprobe_ctlblk {  
  3.     unsigned long kprobe_status;  
  4.     unsigned long kprobe_old_flags;  
  5.     unsigned long kprobe_saved_flags;  
  6.     unsigned long *jprobe_saved_sp;  
  7.     struct pt_regs jprobe_saved_regs;  
  8.     kprobe_opcode_t jprobes_stack[MAX_STACK_SIZE];  
  9.     struct prev_kprobe prev_kprobe;  
  10. };  
该定义比arm结构的多一些字段，其中kprobe_status字段不变，kprobe_old_flags和kprobe_saved_flags字段用于保存寄存器pt_regs的flag标识。

下面回到函数中根据不同的情况分别分析：

1、p存在且curent_kprobe存在

对于kprobe重入的情况，调用reenter_kprobe函数单独处理：

[cpp] view plain copy
  1. if (kprobe_running()) {  
  2.     if (reenter_kprobe(p, regs, kcb))  
  3.         return 1;  
[cpp] view plain copy
  1. /* 
  2.  * We have reentered the kprobe_handler(), since another probe was hit while 
  3.  * within the handler. We save the original kprobes variables and just single 
  4.  * step on the instruction of the new probe without calling any user handlers. 
  5.  */  
  6. static int reenter_kprobe(struct kprobe *p, struct pt_regs *regs,  
  7.               struct kprobe_ctlblk *kcb)  
  8. {  
  9.     switch (kcb->kprobe_status) {  
  10.     case KPROBE_HIT_SSDONE:  
  11.     case KPROBE_HIT_ACTIVE:  
  12.     case KPROBE_HIT_SS:  
  13.         kprobes_inc_nmissed_count(p);  
  14.         setup_singlestep(p, regs, kcb, 1);  
  15.         break;  
  16.     case KPROBE_REENTER:  
  17.         /* A probe has been hit in the codepath leading up to, or just 
  18.          * after, single-stepping of a probed instruction. This entire 
  19.          * codepath should strictly reside in .kprobes.text section. 
  20.          * Raise a BUG or we'll continue in an endless reentering loop 
  21.          * and eventually a stack overflow. 
  22.          */  
  23.         printk(KERN_WARNING "Unrecoverable kprobe detected at %p.\n",  
  24.                p->addr);  
  25.         dump_kprobe(p);  
  26.         BUG();  
  27.     default:  
  28.         /* impossible cases */  
  29.         WARN_ON(1);  
  30.         return 0;  
  31.     }  
  32.   
  33.     return 1;  
  34. }  
  35. NOKPROBE_SYMBOL(reenter_kprobe);  
这个流程同arm实现的很像，只不过对于KPROBE_HIT_SS阶段不会报BUG，也同KPROBE_HIT_SSDONE和KPROBE_HIT_ACTIVE一样，递增nmissed值并调用setup_singlestep函数进入单步处理流程（该函数最后一个入参此时设置为1，针对reenter的情况会将kprobe_status状态设置为KPROBE_REENTER并调用save_previous_kprobe执行保存当前kprobe的操作）。对于KPROBE_REENTER阶段还是直接报BUG。注意最后函数会返回1，do_int3也会直接返回，表示该中断已被kprobe截取并处理，无需再处理其他分支。

2、p存在但curent_kprobe不存在

[cpp] view plain copy
  1. } else {  
  2.     set_current_kprobe(p, regs, kcb);  
  3.     kcb->kprobe_status = KPROBE_HIT_ACTIVE;  
  4.   
  5.     /* 
  6.      * If we have no pre-handler or it returned 0, we 
  7.      * continue with normal processing.  If we have a 
  8.      * pre-handler and it returned non-zero, it prepped 
  9.      * for calling the break_handler below on re-entry 
  10.      * for jprobe processing, so get out doing nothing 
  11.      * more here. 
  12.      */  
  13.     if (!p->pre_handler || !p->pre_handler(p, regs))  
  14.         setup_singlestep(p, regs, kcb, 0);  
  15.     return 1;  
  16. }  

这是一般最通用的kprobe执行流程，首先调用set_current_kprobe绑定p为当前正在处理的kprobe：

[cpp] view plain copy
  1. static nokprobe_inline void  
  2. set_current_kprobe(struct kprobe *p, struct pt_regs *regs,  
  3.            struct kprobe_ctlblk *kcb)  
  4. {  
  5.     __this_cpu_write(current_kprobe, p);  
  6.     kcb->kprobe_saved_flags = kcb->kprobe_old_flags  
  7.         = (regs->flags & (X86_EFLAGS_TF | X86_EFLAGS_IF));  
  8.     if (p->ainsn.if_modifier)  
  9.         kcb->kprobe_saved_flags &= ~X86_EFLAGS_IF;  
  10. }  
这里在设置current_kprobe全局变量的同时，还会同时设置kprobe_saved_flags和kprobe_old_flags的flag值，它们用于具体的架构指令相关处理。接下来处理pre_handler回调函数，有注册的话就调用执行，然后调用setup_singlestep启动单步执行。在调试完成后直接返回1，注意这里并没有向arm实现那样直接调用post_handler回调函数并解除kprobe绑定，因为x86_64架构的post_handler采用另一种方式调用，后文会讲到。

3、p不存在且被探测地址的指令也不是BREAKPOINT_INSTRUCTION

[cpp] view plain copy
  1. } else if (*addr != BREAKPOINT_INSTRUCTION) {  
  2.     /* 
  3.      * The breakpoint instruction was removed right 
  4.      * after we hit it.  Another cpu has removed 
  5.      * either a probepoint or a debugger breakpoint 
  6.      * at this address.  In either case, no further 
  7.      * handling of this interrupt is appropriate. 
  8.      * Back up over the (now missing) int3 and run 
  9.      * the original instruction. 
  10.      */  
  11.     regs->ip = (unsigned long)addr;  
  12.     preempt_enable_no_resched();  
  13.     return 1;  

这种情况表示kprobe可能已经被其他CPU注销了，则让他执行原始指令即可，因此这里设置regs->ip值为addr并重新开启内核抢占返回1。

4、p不存在但curent_kprobe存在

[cpp] view plain copy
  1. } else if (kprobe_running()) {  
  2.     p = __this_cpu_read(current_kprobe);  
  3.     if (p->break_handler && p->break_handler(p, regs)) {  
  4.         if (!skip_singlestep(p, regs, kcb))  
  5.             setup_singlestep(p, regs, kcb, 0);  
  6.         return 1;  
  7.     }  

这种情况一般用于实现jprobe，因此会调用curent_kprobe的break_handler回调函数，然后在break_handler返回非0的情况下执行单步执行，最后返回1。具体在jprobe实现中再详细分析。

以上x86_64架构的kprobe触发及回调整体流程分析完毕，可以看到基本的触发条件和处理流程和arm架构的实现还是差不多的，和架构相关的一些细节有所不同。同时也并没有看到post_handle的回调流程和kprobe的解绑定流程，由于实现同arm不同，以上遗留的两点会在后文分析。接下来分析被探测指令的单步执行过程。


4、单步执行

单步执行其实就是执行被探测点的原始指令，涉及的主要函数即前文中分析kprobe触发及处理流程时遗留的singlestep函数（arm）和setup_singlestep函数（x86），它们的实现原理完全不同，其中会涉及许多cpu架构相关的知识，因此会比较晦涩。下面从原理角度逐一分析，并不涉及太多架构相关的细节：

4.1、arm架构实现

arm架构单步执行的原理并不非常复杂（但是实现非常复杂），它本质上所做的就是执行被探测点的被替换前的“原始指令”，但是当前的上下文已经是kprobe的执行上下文了，不再是原始指令所处的上下文，所以单步执行流程无法直接执行原始指令，而是会调用其他函数来模拟实现原始指令以达到相同的效果，因此涉及的函数很多，基本每条不同的汇编指令都有不同的模拟函数。
[cpp] view plain copy
  1. static inline void __kprobes  
  2. singlestep(struct kprobe *p, struct pt_regs *regs, struct kprobe_ctlblk *kcb)  
  3. {  
  4.     p->ainsn.insn_singlestep(p->opcode, &p->ainsn, regs);  
  5. }  
singlestep函数直接调用保存在arch_probes_insn结构中的insn_singlestep函数指针（该指针在注册kprobe时由arm_probes_decode_insn函数负责初始化），即arm_singlestep函数。入参为保存的被探测点指令、arch_probes_insn结构地址及寄存器参数。
[cpp] view plain copy
  1. static void __kprobes arm_singlestep(probes_opcode_t insn,  
  2.         struct arch_probes_insn *asi, struct pt_regs *regs)  
  3. {  
  4.     regs->ARM_pc += 4;  
  5.     asi->insn_handler(insn, asi, regs);  
  6. }  
首先让寄存器参数中的PC加4，表示kprobe处理完成后将跳过触发kprobe时的KPROBE_ARM_BREAKPOINT_INSTRUCTION指令继续执行。然后调用insn_handler函数指针中设置的注册函数，该函数指针由probes_decode_insn函数根据不同的原始指令被设置为不同的处理函数，它们被定义在kprobes_arm_actions数组中：
[cpp] view plain copy
  1. const union decode_action kprobes_arm_actions[NUM_PROBES_ARM_ACTIONS] = {  
  2.     [PROBES_PRELOAD_IMM] = {.handler = probes_simulate_nop},  
  3.     [PROBES_PRELOAD_REG] = {.handler = probes_simulate_nop},  
  4.     [PROBES_BRANCH_IMM] = {.handler = simulate_blx1},  
  5.     [PROBES_MRS] = {.handler = simulate_mrs},  
  6.     [PROBES_BRANCH_REG] = {.handler = simulate_blx2bx},  
  7.     [PROBES_CLZ] = {.handler = emulate_rd12rm0_noflags_nopc},  
  8.     [PROBES_SATURATING_ARITHMETIC] = {  
  9.         .handler = emulate_rd12rn16rm0_rwflags_nopc},  
  10.     [PROBES_MUL1] = {.handler = emulate_rdlo12rdhi16rn0rm8_rwflags_nopc},  
  11.     [PROBES_MUL2] = {.handler = emulate_rd16rn12rm0rs8_rwflags_nopc},  
  12.     [PROBES_SWP] = {.handler = emulate_rd12rn16rm0_rwflags_nopc},  
  13.     [PROBES_LDRSTRD] = {.handler = emulate_ldrdstrd},  
  14.     ......  
  15. }  
这里的函数众多就不一一分析了，现仍然以do_fork函数的入口指令“mov     ip, sp”为例，调用的函数为simulate_mov_ipsp：
[cpp] view plain copy
  1. void __kprobes simulate_mov_ipsp(probes_opcode_t insn,  
  2.         struct arch_probes_insn *asi, struct pt_regs *regs)  
  3. {  
  4.     regs->uregs[12] = regs->uregs[13];  
  5. }  
这里的uregs[12]即ARM_ip，uregs[13]即ARM_sp，可见simulate_mov_ipsp函数仅仅是模拟实现“mov     ip, sp”指令而已，对触发kprobe前的寄存器状态进行处理。当然这只是其中一个简单的例子，对于其他一些复杂的多周期指令其模拟函数会实现的比较复杂，甚至有一些无法模拟的指令在注册时probes_decode_insn函数就会返回INSN_REJECTED了。

以上arm架构下实现同原始指令同样效果的单步执行就分析完了，在kprobe流程执行完成后，恢复到regs中保存的上下文后就会从ARM_pc处继续取指执行了。这里虽然只分析了mov指令的单步执行，但其他的指令的处理流程类似，若想要了解个中细节可以通过ftrace工具进行跟踪。

4.2、x86_64架构实现

x86_64架构的单步执行函数与arm架构的原理不同，其主要原理是：当程序执行到某条想要单独执行CPU指令时，在执行之前产生一次CPU异常，此时把异常返回时的CPU的EFLAGS寄存器的TF(调试位)位置为1，把IF(中断屏蔽位)标志位置为0，然后把EIP指向单步执行的指令。当单步指令执行完成后，CPU会自动产生一次调试异常（由于TF被置位）。此时，Kprobes会利用debug异常，执行post_handler()。下面来简单看一下：

[cpp] view plain copy
  1. static void setup_singlestep(struct kprobe *p, struct pt_regs *regs,  
  2.                  struct kprobe_ctlblk *kcb, int reenter)  
  3. {  
  4.     if (setup_detour_execution(p, regs, reenter))  
  5.         return;  
  6.   
  7.     ......  
  8.       
  9.     if (reenter) {  
  10.         save_previous_kprobe(kcb);  
  11.         set_current_kprobe(p, regs, kcb);  
  12.         kcb->kprobe_status = KPROBE_REENTER;  
  13.     } else  
  14.         kcb->kprobe_status = KPROBE_HIT_SS;  
  15.     /* Prepare real single stepping */  
  16.     clear_btf();  
  17.     regs->flags |= X86_EFLAGS_TF;  
  18.     regs->flags &= ~X86_EFLAGS_IF;  
  19.     /* single step inline if the instruction is an int3 */  
  20.     if (p->opcode == BREAKPOINT_INSTRUCTION)  
  21.         regs->ip = (unsigned long)p->addr;  
  22.     else  
  23.         regs->ip = (unsigned long)p->ainsn.insn;  
  24. }  
首先在前文中已经介绍了，函数的最后一个入参reenter表示是否重入，对于重入的情况那就调用save_previous_kprobe函数保存当前正在运行的kprobe，然后绑定p和current_kprobe并设置kprobe_status为KPROBE_REENTER；对于非重入的情况则设置kprobe_status为KPROBE_HIT_SS。

接下来考试准备单步执行，首先设置regs->flags中的TF位并清空IF位，同时把int3异常返回的指令寄存器地址改为前面保存的被探测指令，当int3异常返回时这些设置就会生效，即立即执行保存的原始指令（注意这里是在触发int3之前原来的上下文中执行，因此直接执行原始指令即可，无需特别的模拟操作）。该函数返回后do_int3函数立即返回，由于cpu的标识寄存器被设置，在单步执行完被探测指令后立即触发debug异常，进入debug异常处理函数do_debug。

[cpp] view plain copy
  1. dotraplinkage void do_debug(struct pt_regs *regs, long error_code)  
  2. {  
  3.     ......  
  4.       
  5. #ifdef CONFIG_KPROBES  
  6.     if (kprobe_debug_handler(regs))  
  7.         goto exit;  
  8. #endif  
  9.   
  10.     ......  
  11.   
  12. exit:  
  13.     ist_exit(regs, prev_state);  
  14. }  
[cpp] view plain copy
  1. /* 
  2.  * Interrupts are disabled on entry as trap1 is an interrupt gate and they 
  3.  * remain disabled throughout this function. 
  4.  */  
  5. int kprobe_debug_handler(struct pt_regs *regs)  
  6. {  
  7.     struct kprobe *cur = kprobe_running();  
  8.     struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();  
  9.   
  10.     if (!cur)  
  11.         return 0;  
  12.   
  13.     resume_execution(cur, regs, kcb);  
  14.     regs->flags |= kcb->kprobe_saved_flags;  
  15.   
  16.     if ((kcb->kprobe_status != KPROBE_REENTER) && cur->post_handler) {  
  17.         kcb->kprobe_status = KPROBE_HIT_SSDONE;  
  18.         cur->post_handler(cur, regs, 0);  
  19.     }  
  20.   
  21.     /* Restore back the original saved kprobes variables and continue. */  
  22.     if (kcb->kprobe_status == KPROBE_REENTER) {  
  23.         restore_previous_kprobe(kcb);  
  24.         goto out;  
  25.     }  
  26.     reset_current_kprobe();  
  27. out:  
  28.     preempt_enable_no_resched();  
  29.   
  30.     /* 
  31.      * if somebody else is singlestepping across a probe point, flags 
  32.      * will have TF set, in which case, continue the remaining processing 
  33.      * of do_debug, as if this is not a probe hit. 
  34.      */  
  35.     if (regs->flags & X86_EFLAGS_TF)  
  36.         return 0;  
  37.   
  38.     return 1;  
  39. }  
  40. NOKPROBE_SYMBOL(kprobe_debug_handler);  
首先调用resume_execution函数将debug异常返回的下一条指令设置为被探测之后的指令，这样异常返回后程序的流程就会按正常的流程继续执行；然后恢复kprobe执行前保存的flags标识；接下来如果kprobe不是重入的并且设置了post_handler回调函数，就设置kprobe_status状态为KPROBE_HIT_SSDONE并调用post_handler函数；如果是重入的kprobe则调用restore_previous_kprobe函数恢复之前保存的kprobe。最后调用reset_current_kprobe函数解除本kprobe和current_kprobe的绑定，如果本kprobe由单步执行触发，则说明do_debug异常处理还有其他流程带处理，返回0，否则返回1。

以上x86_64的单步执行和post_handler回调分析完毕，简单总结一下和arm架构的实现区别：arm结构的单步执行被探测指令是在异常处理上下文中进行的，因此需要使用单独的函数来模拟实现原始命令所操作的流程，而x86_64架构则利用了cpu提供的单步调试技术，使得原始指令在正常的原上下文中执行，而两个回调函数则分别在int3和debug两次异常处理流程中执行。

至此，kprobe的一般处理流程就分析完了，最后分析一下剩下的最后一个回调函数fault_handler。


5、出错回调

出错会调函数fault_handler会在执行pre_handler、single_step和post_handler期间触发内存异常时被调用，对应的调用函数为kprobe_fault_handler，它同样时架构相关的，分别来看一下：

5.1、arm调用流程

do_page_fault->notify_page_fault

[cpp] view plain copy
  1. static inline int notify_page_fault(struct pt_regs *regs, unsigned int fsr)  
  2. {  
  3.     int ret = 0;  
  4.   
  5.     if (!user_mode(regs)) {  
  6.         /* kprobe_running() needs smp_processor_id() */  
  7.         preempt_disable();  
  8.         if (kprobe_running() && kprobe_fault_handler(regs, fsr))  
  9.             ret = 1;  
  10.         preempt_enable();  
  11.     }  
  12.   
  13.     return ret;  
  14. }  
可见在触发缺页异常之后，若当前正在处理kprobe流程期间，会调用kprobe_fault_handler进行处理。
[cpp] view plain copy
  1. int __kprobes kprobe_fault_handler(struct pt_regs *regs, unsigned int fsr)  
  2. {  
  3.     struct kprobe *cur = kprobe_running();  
  4.     struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();  
  5.   
  6.     switch (kcb->kprobe_status) {  
  7.     case KPROBE_HIT_SS:  
  8.     case KPROBE_REENTER:  
  9.         /* 
  10.          * We are here because the instruction being single 
  11.          * stepped caused a page fault. We reset the current 
  12.          * kprobe and the PC to point back to the probe address 
  13.          * and allow the page fault handler to continue as a 
  14.          * normal page fault. 
  15.          */  
  16.         regs->ARM_pc = (long)cur->addr;  
  17.         if (kcb->kprobe_status == KPROBE_REENTER) {  
  18.             restore_previous_kprobe(kcb);  
  19.         } else {  
  20.             reset_current_kprobe();  
  21.         }  
  22.         break;  
  23.   
  24.     case KPROBE_HIT_ACTIVE:  
  25.     case KPROBE_HIT_SSDONE:  
  26.         /* 
  27.          * We increment the nmissed count for accounting, 
  28.          * we can also use npre/npostfault count for accounting 
  29.          * these specific fault cases. 
  30.          */  
  31.         kprobes_inc_nmissed_count(cur);  
  32.   
  33.         /* 
  34.          * We come here because instructions in the pre/post 
  35.          * handler caused the page_fault, this could happen 
  36.          * if handler tries to access user space by 
  37.          * copy_from_user(), get_user() etc. Let the 
  38.          * user-specified handler try to fix it. 
  39.          */  
  40.         if (cur->fault_handler && cur->fault_handler(cur, regs, fsr))  
  41.             return 1;  
  42.         break;  
  43.   
  44.     default:  
  45.         break;  
  46.     }  
  47.   
  48.     return 0;  
  49. }  
kprobe_fault_handler函数会找到当前正在处理的kprobe，然后根据处理状态的不同本别处理。首先若是单步执行或是重入的情况，则说明单步执行是发生了内存错误，则复位当前正在处理的kprobe，同时设置PC指针为异常触发指令地址，就好像它是一个普通的缺页异常，由内核后续的处理流程处理；若是执行pre_handler和post_handler回调函数期间出错，则递增kprobe的nmiss字段值，然后调用fault_handler回调函数执行用户指定的操作，如果fault_handler函数返回0则会由内核继续处理page fault，否则表示fault_handler函数已经执行了修复操作，do_page_fault会直接返回。

5.2、x86_64调用流程

1、do_page_fault->__do_page_fault->kprobes_fault

[cpp] view plain copy
  1. static nokprobe_inline int kprobes_fault(struct pt_regs *regs)  
  2. {  
  3.     int ret = 0;  
  4.   
  5.     /* kprobe_running() needs smp_processor_id() */  
  6.     if (kprobes_built_in() && !user_mode(regs)) {  
  7.         preempt_disable();  
  8.         if (kprobe_running() && kprobe_fault_handler(regs, 14))  
  9.             ret = 1;  
  10.         preempt_enable();  
  11.     }  
  12.   
  13.     return ret;  
  14. }  
这个缺页异常的调用流程同arm实现的几乎完全一样，就不赘述了。

2、do_general_protection->notify_die->kprobe_exceptions_notify

[cpp] view plain copy
  1. int kprobe_exceptions_notify(struct notifier_block *self, unsigned long val,  
  2.                  void *data)  
  3. {  
  4.     struct die_args *args = data;  
  5.     int ret = NOTIFY_DONE;  
  6.   
  7.     if (args->regs && user_mode(args->regs))  
  8.         return ret;  
  9.   
  10.     if (val == DIE_GPF) {  
  11.         /* 
  12.          * To be potentially processing a kprobe fault and to 
  13.          * trust the result from kprobe_running(), we have 
  14.          * be non-preemptible. 
  15.          */  
  16.         if (!preemptible() && kprobe_running() &&  
  17.             kprobe_fault_handler(args->regs, args->trapnr))  
  18.             ret = NOTIFY_STOP;  
  19.     }  
  20.     return ret;  
  21. }  
前文中init_kprobes初始化时会注册die内核通知链kprobe_exceptions_nb，它的回调函数为kprobe_exceptions_notify，在内核触发DIE_GPF类型的notify_die时，该函数会调用kprobe_fault_handler进行处理。下面来简单看一下x86_64架构的kprobe_fault_handler函数实现：
[cpp] view plain copy
  1. int kprobe_fault_handler(struct pt_regs *regs, int trapnr)  
  2. {  
  3.     struct kprobe *cur = kprobe_running();  
  4.     struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();  
  5.   
  6.     if (unlikely(regs->ip == (unsigned long)cur->ainsn.insn)) {  
  7.         /* This must happen on single-stepping */  
  8.         WARN_ON(kcb->kprobe_status != KPROBE_HIT_SS &&  
  9.             kcb->kprobe_status != KPROBE_REENTER);  
  10.         /* 
  11.          * We are here because the instruction being single 
  12.          * stepped caused a page fault. We reset the current 
  13.          * kprobe and the ip points back to the probe address 
  14.          * and allow the page fault handler to continue as a 
  15.          * normal page fault. 
  16.          */  
  17.         regs->ip = (unsigned long)cur->addr;  
  18.         regs->flags |= kcb->kprobe_old_flags;  
  19.         if (kcb->kprobe_status == KPROBE_REENTER)  
  20.             restore_previous_kprobe(kcb);  
  21.         else  
  22.             reset_current_kprobe();  
  23.         preempt_enable_no_resched();  
  24.     } else if (kcb->kprobe_status == KPROBE_HIT_ACTIVE ||  
  25.            kcb->kprobe_status == KPROBE_HIT_SSDONE) {  
  26.         /* 
  27.          * We increment the nmissed count for accounting, 
  28.          * we can also use npre/npostfault count for accounting 
  29.          * these specific fault cases. 
  30.          */  
  31.         kprobes_inc_nmissed_count(cur);  
  32.   
  33.         /* 
  34.          * We come here because instructions in the pre/post 
  35.          * handler caused the page_fault, this could happen 
  36.          * if handler tries to access user space by 
  37.          * copy_from_user(), get_user() etc. Let the 
  38.          * user-specified handler try to fix it first. 
  39.          */  
  40.         if (cur->fault_handler && cur->fault_handler(cur, regs, trapnr))  
  41.             return 1;  
  42.   
  43.         /* 
  44.          * In case the user-specified fault handler returned 
  45.          * zero, try to fix up. 
  46.          */  
  47.         if (fixup_exception(regs))  
  48.             return 1;  
  49.   
  50.         /* 
  51.          * fixup routine could not handle it, 
  52.          * Let do_page_fault() fix it. 
  53.          */  
  54.     }  
  55.   
  56.     return 0;  
  57. }  
流程基本同arm实现的完全一致，唯一不同之处在于如果fault_handler函数返回0，即没有修复内存异常，则会直接调用fixup_exception函数尝试修复。

以上fault_handler回调函数分析完毕。

五、总结

kprobes内核探测技术作为一种内核代码的跟踪及调试手段，开发人员可以动态的跟踪内核函数的执行，相较与传统的添加内核日志等调试手段，它具有操作简单，使用灵活，对原始代码破坏小等多方面优势。本文首先介绍了kprobes的技术背景，然后介绍了其中kprobe技术使用方法并且通过源代码详细分析了arm架构和x86_64架构的原理和实现方式。下一篇博文将介绍基于kprobe实现的jprobe内核跟踪技术。


参考文献：1、http://blog.chinaunix.NET/uid-20662820-id-3795534.html

2、http://blog.csdn.net/panfengyun12345/article/details/19480567

3、Documentation/kprobes.txt

4、Documentation/trace/kprobetrace.txt

你可能感兴趣的:(Linux,linux,kprobe,ftrace)

  • android系统selinux中添加新属性property 辉色投像
    1.定位/android/system/sepolicy/private/property_contexts声明属性开头：persist.charge声明属性类型：u:object_r:system_prop:s0图12.定位到android/system/sepolicy/public/domain.te删除neverallow{domain-init}default_prop:property
  • Linux下QT开发的动态库界面弹出操作（SDL2） 13jjyao QT类qt开发语言sdl2linux
    需求：操作系统为linux，开发框架为qt，做成需带界面的qt动态库，调用方为java等非qt程序难点：调用方为java等非qt程序，也就是说调用方肯定不带QApplication::exec()，缺少了这个，QTimer等事件和QT创建的窗口将不能弹出(包括opencv也是不能弹出)；这与qt调用本身qt库是有本质的区别的思路：1.调用方缺QApplication::exec()，那么我们在接口
  • linux sdl windows.h,Windows下的SDL安装 奔跑吧linux内核 linuxsdlwindows.h
    首先你要下载并安装SDL开发包。如果装在C盘下，路径为C:\SDL1.2.5如果在WINDOWS下。你可以按以下步骤：1.打开VC++，点击"Tools",Options2,点击directories选项3.选择"Includefiles"增加一个新的路径。"C:\SDL1.2.5\include"4，现在选择"Libaryfiles“增加"C:\SDL1.2.5\lib"现在你可以开始编写你的第
  • linux中sdl的使用教程,sdl使用入门 Melissa Corvinus linux中sdl的使用教程
    本文通过一个简单示例讲解SDL的基本使用流程。示例中展示一个窗口，窗口里面有个随机颜色快随机移动。当我们鼠标点击关闭按钮时间窗口关闭。基本步骤如下：1.初始化SDL并创建一个窗口。SDL_Init()初始化SDL_CreateWindow()创建窗口2.纹理渲染存储RGB和存储纹理的区别：比如一个从左到右由红色渐变到蓝色的矩形，用存储RGB的话就需要把矩形中每个点的具体颜色值存储下来；而纹理只是一
  • PHP环境搭建详细教程 好看资源平台 前端php
    PHP是一个流行的服务器端脚本语言，广泛用于Web开发。为了使PHP能够在本地或服务器上运行，我们需要搭建一个合适的PHP环境。本教程将结合最新资料，介绍在不同操作系统上搭建PHP开发环境的多种方法，包括Windows、macOS和Linux系统的安装步骤，以及本地和Docker环境的配置。1.PHP环境搭建概述PHP环境的搭建主要分为以下几类：集成开发环境：例如XAMPP、WAMP、MAMP，这
  • 使用 FinalShell 进行远程连接（ssh 远程连接 Linux 服务器） 编程经验分享 开发工具服务器sshlinux
    目录前言基本使用教程新建远程连接连接主机自定义命令路由追踪前言后端开发，必然需要和服务器打交道，部署应用，排查问题，查看运行日志等等。一般服务器都是集中部署在机房中，也有一些直接是云服务器，总而言之，程序员不可能直接和服务器直接操作，一般都是通过ssh连接来登录服务器。刚接触远程连接时，使用的是XSHELL来远程连接服务器，连接上就能够操作远程服务器了，但是仅用XSHELL并没有上传下载文件的功能
  • libyuv之linux编译 jaronho Linuxlinux运维服务器
    文章目录一、下载源码二、编译源码三、注意事项1、银河麒麟系统（aarch64）（1）解决armv8-a+dotprod+i8mm指令集支持问题（2）解决armv9-a+sve2指令集支持问题一、下载源码到GitHub网站下载https://github.com/lemenkov/libyuv源码，或者用直接用git克隆到本地，如：gitclonehttps://github.com/lemenko
  • ARM驱动学习之5 LEDS驱动 JT灬新一 嵌入式C底层arm开发学习单片机
    ARM驱动学习之5LEDS驱动知识点：•linuxGPIO申请函数和赋值函数–gpio_request–gpio_set_value•三星平台配置GPIO函数–s3c_gpio_cfgpin•GPIO配置输出模式的宏变量–S3C_GPIO_OUTPUT注意点：DRIVER_NAME和DEVICE_NAME匹配。实现步骤：1.加入需要的头文件：//Linux平台的gpio头文件#include//三
  • 【华为OD技术面试真题精选 - 非技术题】 -HR面，综合面_华为od hr面 一个射手座的程序媛 程序员华为od面试职场和发展
    最后的话最近很多小伙伴找我要Linux学习资料，于是我翻箱倒柜，整理了一些优质资源，涵盖视频、电子书、PPT等共享给大家！资料预览给大家整理的视频资料：给大家整理的电子书资料：如果本文对你有帮助，欢迎点赞、收藏、转发给朋友，让我有持续创作的动力！网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。需要这份系统化的资料的朋友，可以点击这里获
  • 简介Shell、zsh、bash zhaosuningsn Shellzshbashshelllinuxbash
    Shell是Linux和Unix的外壳，类似衣服，负责外界与Linux和Unix内核的交互联系。例如接收终端用户及各种应用程序的命令，把接收的命令翻译成内核能理解的语言，传递给内核，并把内核处理接收的命令的结果返回给外界，即Shell是外界和内核沟通的桥梁或大门。Linux和Unix提供了多种Shell，其中有种bash，当然还有其他好多种。Mac电脑中不但有bash，还有一个zsh，预装的，据说
  • Linux MariaDB使用OpenSSL安装SSL证书 Meta39 MySQLOracleMariaDBLinuxWindowsssllinuxmariadb
    进入到证书存放目录，批量删除.pem证书警告：确保已经进入到证书存放目录find.-typef-iname\*.pem-delete查看是否安装OpenSSLopensslversion没有则安装yuminstallopensslopenssl-devel开启SSL编辑/etc/my.cnf文件（没有的话就创建，但是要注意，在/etc/my.cnf.d/server.cnf配置了datadir的，
  • 【从浅识到熟知Linux】Linux发展史 Jammingpro 从浅学到熟知Linuxlinux运维服务器
    归属专栏：从浅学到熟知Linux个人主页：Jammingpro每日努力一点点，技术变化看得见文章前言：本篇文章记录Linux发展的历史，因在介绍Linux过程中涉及的其他操作系统及人物，本文对相关内容也有所介绍。文章目录Unix发展史Linux发展史开源Linux官网企业应用情况发行版本在学习Linux前，我们可能都会问Linux从哪里来？它是如何发展的。但在介绍Linux之前，需要先介绍一下Un
  • linux 发展史 种树的猴子 内核java操作系统linux大数据
    linux发展史说明此前对linux认识模糊一知半解，近期通过学习将自己对于linux的发展总结一下方便大家日后的学习。那Linux是目前一款非常火热的开源操作系统，可是linux是什么时候出现的，又是因为什么样的原因被开发出来的呢。以下将对linux的发展历程进行详细的讲解。目录一、Linux发展背景二、UINIX的诞生三、UNIX的重要分支-BSD的诞生四、Minix的诞生五、GNU与Free
  • Linux sh命令 fengyehongWorld Linuxlinux
    目录一.基本语法二.选项2.1-c字符串中读取内容，并执行2.1.1基本用法2.1.2获取当前目录下失效的超链接2.2-x每个命令执行之前，将其打印出来2.3结合Here文档使用一.基本语法⏹Linux和Unix系统中用于执行shell脚本或运行命令的命令。sh[选项][脚本文件][参数...]⏹选项-c：从字符串中读取内容，并执行。-x：在每个命令执行之前，将其打印出来。-s：从标准流中读取内容
  • Linux vi常用命令 fengyehongWorld Linuxlinux
    参考资料viコマンド（vimコマンド）リファレンス目录一.保存系命令二.删除系命令三.移动系命令四.复制粘贴系命令一.保存系命令⏹保存并退出:wq⏹强制保存并退出:wq!⏹退出(文件未编辑):q⏹强制退出(忽略已编辑内容):q!⏹另存为:w新文件名二.删除系命令⏹删除当前行dd⏹清空整个文档gg：移动到文档顶部dG：删除到最后一行ggdG三.移动系命令⏹移动到文档顶部gg⏹移动到文档底部#方式1G
  • Linux查看服务器日志 TPBoreas 运维linux运维
    一、tail这个是我最常用的一种查看方式用法如下：tail-n10test.log查询日志尾部最后10行的日志;tail-n+10test.log查询10行之后的所有日志;tail-fn10test.log循环实时查看最后1000行记录(最常用的)一般还会配合着grep用，(实时抓包)例如:tail-fn1000test.log|grep'关键字'（动态抓包）tail-fn1000test.log
  • 笋丁网页自动回复机器人V3.0.0免授权版源码 希希分享 软希网58soho_cn源码资源笋丁网页自动回复机器人
    笋丁网页机器人一款可设置自动回复，默认消息，调用自定义api接口的网页机器人。此程序后端语言使用Golang，内存占用最高不超过30MB，1H1G服务器流畅运行。仅支持Linux服务器部署，不支持虚拟主机，请悉知！使用自定义api功能需要有一定的建站基础。源码下载：https://download.csdn.net/download/m0_66047725/89754250更多资源下载：关注我。安
  • Linux CTF逆向入门 蚁景网络安全 linux运维CTF
    1.ELF格式我们先来看看ELF文件头，如果想详细了解，可以查看ELF的manpage文档。关于ELF更详细的说明：e_shoff：节头表的文件偏移量（字节）。如果文件没有节头表，则此成员值为零。sh_offset：表示了该section（节）离开文件头部位置的距离+-------------------+|ELFheader|---++--------->+-------------------
  • NPM私库搭建-verdaccio（Linux） Beam007 npmlinux前端
    1、安装nodelinux服务器安装nodea)、官网下载所需的node版本https://nodejs.org/dist/v14.21.0/b)、解压安装包若下载的是xxx.tar.xz文件，解压命令为tar-xvfxxx.tar.xzc)、修改环境变量修改：/etc/profile文件#SETPATHFORNODEJSexportNODE_HOME=NODEJS解压安装的路径exportPAT
  • C++常见知识掌握 nfgo c++开发语言
    1.Linux软件开发、调试与维护内核与系统结构Linux内核是操作系统的核心，负责管理硬件资源，提供系统服务，它是系统软件与硬件之间的桥梁。主要组成部分包括：进程管理：内核通过调度器分配CPU时间给各个进程，实现进程的创建、调度、终止等操作。使用进程描述符（task_struct）来存储进程信息，包括状态（就绪、运行、阻塞等）、优先级、内存映射等。内存管理：包括物理内存和虚拟内存管理。通过页表映
  • linux脚本sed替换变量,sed 命令中替换值为shell变量 诺坎普之约 linux脚本sed替换变量
    文章目录sed命令中替换值为shell变量替换基本语法sed中替换使用shell变量总结参考文档sed命令中替换值为shell变量替换基本语法大家都是sed有很多用法，最多就应该是替换一些值了。让我们先回忆sed的替换语法。在sed进行替换的时候sed-i's/old/new/g'1.txtecho"hellooldfrank"|sed's/old/new/g'结果如下：hellonewfrank
  • RK3229_Android9.0_Box 4G模块EC200A调试 suifen_ 网络
    0、kernel修改这部分完全可以参考Linux的移植：RK3588EC200A-CN【4G模块】调试_rkec200a-cn-CSDN博客1、修改device/rockchip/rk322xdiff--gita/device.mkb/device.mkindexec6bfaa..e7c32d1100755---a/device.mk+++b/device.mk@@-105,6+105,8@@en
  • linux 安装Sublime Text 3 hhyiyuanyu Python学习linuxsublimetext
    方法/步骤打开官网http://www.sublimetext.com/3，选择64位进行下载执行命令wgethttps://download.sublimetext.com/sublime_text_3_build_3126_x64.tar.bz2进行下载3、下载完成进行解压,执行tar-xvvfsublime_text_3_build_3126_x64.tar.bz解压4、解压完成以后，移动到
  • KVM虚拟机源代码分析【转】 xidianjiapei001 #虚拟化技术
    1.KVM结构及工作原理1.1KVM结构KVM基本结构有两部分组成。一个是KVMDriver，已经成为Linux内核的一个模块。负责虚拟机的创建，虚拟内存的分配，虚拟CPU寄存器的读写以及虚拟CPU的运行等。另外一个是稍微修改过的Qemu，用于模拟PC硬件的用户空间组件，提供I/O设备模型以及访问外设的途径。KVM基本结构如图1所示。其中KVM加入到标准的Linux内核中，被组织成Linux中标准
  • 史上最全git命令,git回滚,git命令大全 騒周 其他git
    git命令大全一、Git整体理解二、由暂存区本地仓库三、由本地仓->远程仓库四、冲突处理五、Git分支操作六、bug的分支七、feature分支八、暂存的使用九、远程仓的操作十、标签的使用十一、Git配置全局信息十二、Linux的一些简单操作和一些符号的解释十三、符号解释十四、显示安装详细信息十五、gitconfig十六、Gitclone十七、Gitinit十八、gitstatus十九、gitre
  • 【显示 后台运行 & 的命令】 晨春计 debuglinux服务器运维
    目录背景步骤详解示例背景当你在Linuxshell中使用&符号将一个命令放到后台运行时，你可以使用jobs命令来查看这些后台进程的状态。但是，jobs命令并不会直接显示进程的PID（进程ID）。它会显示一个作业列表，其中包括每个作业的状态和一个作业标识符（通常是百分号%后面跟着一个数字），但不会直接显示PID。获取后台进程的PID步骤：1、使用jobs命令查看后台作业。2、使用ps命令配合grep
  • Android shell 常用 debug 命令 晨春计 Audiodebugandroidlinux
    目录1、查看版本2、am命令3、pm命令4、dumpsys命令5、sed命令6、log定位查看APK进程号7、log定位使用场景1、查看版本1.1、Android串口终端执行getpropro.build.version.release#获取Android版本uname-a#查看linux内核版本信息uname-r#单独查看内核版本1.2、linux服务器执行lsb_release-a#查看Lin
  • 【nginx】ngx_http_proxy_connect_module 正向代理 等风来不如迎风去 网络服务入门与实战nginxhttp运维
    50.65无法访问服务器，(403错误)50.196可以访问服务器。那么，配置65通过196访问。需要一个nginx作为代理【nginx】搭配okhttp配置反向代理发送原生的nginx是不支持okhttp的CONNECT请求的。大神竟然给出了一个java工程GINX编译ngx_http_proxy_connect_module及做正向代理是linux构建的。是windows构建的：编译Windo
  • linux下好用的任务管理器htop WittXie Linuxlinux服务器运维
    给大家推荐个好用的任务管理器htop，简直好用的不得了。完虐top。不解释了，看文章！！！在Linux系统中，top命令用来显示系统中正在运行的进程的实时状态，它显示了一些非常有用的信息，比如CPU利用情况、内存消耗情况，以及每个进程情况等。但是，你知道吗？还有另外一个命令行工具'htop'，它与传统的top命令功能一样，但它有更加强大的功能及能显示更多的信息。这篇文章，我们会用实例来讨论这个'h
  • Linux下使用U盘 WittXie Linuxlinux运维服务器
    第一步：插入U盘，如果能够识别出U盘，则会打印出一些信息；第二步：查看U盘系统分配给U盘的设备名；输入如下命令进行查看：fdisk-l/dev/sda如果打印出如下信息：Disk/dev/sda:4233MB,4233101312bytes165heads,34sectors/track,1473cylindersUnits=cylindersof5610*512=2872320bytesDevi
  • HQL之投影查询 归来朝歌 HQLHibernate查询语句投影查询
            在HQL查询中，常常面临这样一个场景，对于多表查询，是要将一个表的对象查出来还是要只需要每个表中的几个字段，最后放在一起显示？ 针对上面的场景，如果需要将一个对象查出来： HQL语句写“from 对象”即可 Session session = HibernateUtil.openSession();
  • Spring整合redis bylijinnan redis
    pom.xml <dependencies> <!-- Spring Data - Redis Library --> <dependency> <groupId>org.springframework.data</groupId> <artifactId>spring-data-redi
  • org.hibernate.NonUniqueResultException: query did not return a unique result: 2 0624chenhong Hibernate
    参考：http://blog.csdn.net/qingfeilee/article/details/7052736 org.hibernate.NonUniqueResultException: query did not return a unique result: 2         在项目中出现了org.hiber
  • android动画效果 不懂事的小屁孩 android动画
    前几天弄alertdialog和popupwindow的时候，用到了android的动画效果，今天专门研究了一下关于android的动画效果，列出来，方便以后使用。 Android 平台提供了两类动画。 一类是Tween动画，就是对场景里的对象不断的进行图像变化来产生动画效果（旋转、平移、放缩和渐变）。 第二类就是 Frame动画，即顺序的播放事先做好的图像，与gif图片原理类似。
  • js delete 删除机理以及它的内存泄露问题的解决方案 换个号韩国红果果 JavaScript
    delete删除属性时只是解除了属性与对象的绑定，故当属性值为一个对象时，删除时会造成内存泄露  （其实还未删除） 举例： var person={name:{firstname:'bob'}} var p=person.name delete person.name p.firstname -->'bob' // 依然可以访问p.firstname，存在内存泄露
  • Oracle将零干预分析加入网络即服务计划 蓝儿唯美 oracle
    由Oracle通信技术部门主导的演示项目并没有在本月较早前法国南斯举行的行业集团TM论坛大会中获得嘉奖。但是，Oracle通信官员解雇致力于打造一个支持零干预分配和编制功能的网络即服务（NaaS）平台，帮助企业以更灵活和更适合云的方式实现通信服务提供商（CSP）的连接产品。这个Oracle主导的项目属于TM Forum Live!活动上展示的Catalyst计划的19个项目之一。Catalyst计
  • spring学习——springmvc（二） a-john springMVC
    Spring MVC提供了非常方便的文件上传功能。 1，配置Spring支持文件上传： DispatcherServlet本身并不知道如何处理multipart的表单数据，需要一个multipart解析器把POST请求的multipart数据中抽取出来，这样DispatcherServlet就能将其传递给我们的控制器了。为了在Spring中注册multipart解析器，需要声明一个实现了Mul
  • POJ-2828-Buy Tickets aijuans ACM_POJ
    POJ-2828-Buy Tickets http://poj.org/problem?id=2828 线段树，逆序插入 #include<iostream>#include<cstdio>#include<cstring>#include<cstdlib>using namespace std;#define N 200010struct
  • Java Ant build.xml详解 asia007 build.xml
    1,什么是antant是构建工具2,什么是构建概念到处可查到，形象来说，你要把代码从某个地方拿来，编译，再拷贝到某个地方去等等操作，当然不仅与此，但是主要用来干这个3,ant的好处跨平台   --因为ant是使用java实现的，所以它跨平台使用简单--与ant的兄弟make比起来语法清晰--同样是和make相比功能强大--ant能做的事情很多，可能你用了很久，你仍然不知道它能有
  • android按钮监听器的四种技术 百合不是茶 androidxml配置监听器实现接口
    android开发中经常会用到各种各样的监听器,android监听器的写法与java又有不同的地方;    1,activity中使用内部类实现接口 ,创建内部类实例  使用add方法  与java类似   创建监听器的实例 myLis lis = new myLis();   使用add方法给按钮添加监听器  
  • 软件架构师不等同于资深程序员 bijian1013 程序员架构师架构设计
            本文的作者Armel Nene是ETAPIX Global公司的首席架构师，他居住在伦敦，他参与过的开源项目包括 Apache Lucene,，Apache Nutch， Liferay 和 Pentaho等。         如今很多的公司
  • TeamForge Wiki Syntax & CollabNet User Information Center sunjing TeamForgeHow doAttachementAnchorWiki Syntax
    the CollabNet user information center http://help.collab.net/   How do I create a new Wiki page? A CollabNet TeamForge project can have any number of Wiki pages. All Wiki pages are linked, and
  • 【Redis四】Redis数据类型 bit1129 redis
    概述 Redis是一个高性能的数据结构服务器，称之为数据结构服务器的原因是，它提供了丰富的数据类型以满足不同的应用场景，本文对Redis的数据类型以及对这些类型可能的操作进行总结。 Redis常用的数据类型包括string、set、list、hash以及sorted set.Redis本身是K/V系统，这里的数据类型指的是value的类型，而不是key的类型，key的类型只有一种即string
  • SSH2整合-附源码 白糖_ eclipsespringtomcatHibernateGoogle
    今天用eclipse终于整合出了struts2+hibernate+spring框架。 我创建的是tomcat项目，需要有tomcat插件。导入项目以后，鼠标右键选择属性，然后再找到“tomcat”项，勾选一下“Is a tomcat project”即可。具体方法见源码里的jsp图片，sql也在源码里。     补充1：项目中部分jar包不是最新版的，可能导
  • [转]开源项目代码的学习方法 braveCS 学习方法
    转自： http://blog.sina.com.cn/s/blog_693458530100lk5m.html http://www.cnblogs.com/west-link/archive/2011/06/07/2074466.html   1）阅读features。以此来搞清楚该项目有哪些特性2）思考。想想如果自己来做有这些features的项目该如何构架3）下载并安装d
  • 编程之美-子数组的最大和（二维） bylijinnan 编程之美
    package beautyOfCoding; import java.util.Arrays; import java.util.Random; public class MaxSubArraySum2 { /** * 编程之美 子数组之和的最大值（二维） */ private static final int ROW = 5; private stat
  • 读书笔记-3 chengxuyuancsdn jquery笔记resultMap配置ibatis一对多配置
    1、resultMap配置 2、ibatis一对多配置 3、jquery笔记 1、resultMap配置 当<select resultMap="topic_data"> <resultMap id="topic_data">必须一一对应。 (1)<resultMap class="tblTopic&q
  • [物理与天文]物理学新进展 comsci
          如果我们必须获得某种地球上没有的矿石,才能够进行某些能量输出装置的设计和建造,而要获得这种矿石,又必须首先进行深空探测,而要进行深空探测,又必须获得这种能量输出装置,这个矛盾的循环,会导致地球联盟在与宇宙文明建立关系的时候,陷入困境       怎么办呢?  
  • Oracle 11g新特性:Automatic Diagnostic Repository daizj oracleADR
    Oracle Database 11g的FDI（Fault Diagnosability Infrastructure）是自动化诊断方面的又一增强。 FDI的一个关键组件是自动诊断库（Automatic Diagnostic Repository-ADR）。 在oracle 11g中，alert文件的信息是以xml的文件格式存在的，另外提供了普通文本格式的alert文件。 这两份log文
  • 简单排序:选择排序 dieslrae 选择排序
    public void selectSort(int[] array){ int select; for(int i=0;i<array.length;i++){ select = i; for(int k=i+1;k<array.leng
  • C语言学习六指针的经典程序，互换两个数字 dcj3sjt126com c
    示例程序，swap_1和swap_2都是错误的，推理从1开始推到2，2没完成，推到3就完成了 # include <stdio.h> void swap_1(int, int); void swap_2(int *, int *); void swap_3(int *, int *); int main(void) { int a = 3; int b =
  • php 5.4中php-fpm 的重启、终止操作命令 dcj3sjt126com PHP
    php 5.4中php-fpm 的重启、终止操作命令: 查看php运行目录命令：which php/usr/bin/php 查看php-fpm进程数：ps aux | grep -c php-fpm 查看运行内存/usr/bin/php  -i|grep mem 重启php-fpm/etc/init.d/php-fpm restart 在phpinfo()输出内容可以看到php
  • 线程同步工具类 shuizhaosi888 同步工具类
    同步工具类包括信号量（Semaphore）、栅栏（barrier）、闭锁（CountDownLatch）   闭锁（CountDownLatch） public class RunMain { public long timeTasks(int nThreads, final Runnable task) throws InterruptedException { fin
  • bleeding edge是什么意思 haojinghua DI
    不止一次，看到很多讲技术的文章里面出现过这个词语。今天终于弄懂了——通过朋友给的浏览软件，上了wiki。  我再一次感到，没有辞典能像WiKi一样，给出这样体贴人心、一清二楚的解释了。为了表达我对WiKi的喜爱，只好在此一一中英对照，给大家上次课。   In computer science, bleeding edge is a term that
  • c中实现utf8和gbk的互转 jimmee ciconvutf8&gbk编码
    #include <iconv.h> #include <stdlib.h> #include <stdio.h> #include <unistd.h> #include <fcntl.h> #include <string.h> #include <sys/stat.h> int code_c
  • 大型分布式网站架构设计与实践 lilin530 应用服务器搜索引擎
    1.大型网站软件系统的特点？ a.高并发，大流量。 b.高可用。 c.海量数据。 d.用户分布广泛，网络情况复杂。 e.安全环境恶劣。 f.需求快速变更，发布频繁。 g.渐进式发展。 2.大型网站架构演化发展历程？ a.初始阶段的网站架构。 应用程序，数据库，文件等所有的资源都在一台服务器上。 b.应用服务器和数据服务器分离。 c.使用缓存改善网站性能。 d.使用应用
  • 在代码中获取Android theme中的attr属性值 OliveExcel androidtheme
    Android的Theme是由各种attr组合而成, 每个attr对应了这个属性的一个引用, 这个引用又可以是各种东西.   在某些情况下, 我们需要获取非自定义的主题下某个属性的内容 (比如拿到系统默认的配色colorAccent), 操作方式举例一则: int defaultColor = 0xFF000000; int[] attrsArray = { andorid.r.
  • 基于Zookeeper的分布式共享锁 roadrunners zookeeper分布式共享锁
    首先，说说我们的场景，订单服务是做成集群的，当两个以上结点同时收到一个相同订单的创建指令，这时并发就产生了，系统就会重复创建订单。等等......场景。这时，分布式共享锁就闪亮登场了。   共享锁在同一个进程中是很容易实现的，但在跨进程或者在不同Server之间就不好实现了。Zookeeper就很容易实现。具体的实现原理官网和其它网站也有翻译，这里就不在赘述了。   官
  • 两个容易被忽略的MySQL知识 tomcat_oracle mysql
    1、varchar(5)可以存储多少个汉字，多少个字母数字？ 　　相信有好多人应该跟我一样，对这个已经很熟悉了，根据经验我们能很快的做出决定，比如说用varchar(200)去存储url等等，但是，即使你用了很多次也很熟悉了，也有可能对上面的问题做出错误的回答。 　　这个问题我查了好多资料，有的人说是可以存储5个字符，2.5个汉字（每个汉字占用两个字节的话），有的人说这个要区分版本，5.0
  • zoj 3827 Information Entropy(水题) 阿尔萨斯 format
    题目链接：zoj 3827 Information Entropy 题目大意：三种底，计算和。 解题思路：调用库函数就可以直接算了，不过要注意Pi = 0的时候，不过它题目里居然也讲了。。。limp→0+plogb(p)=0，因为p是logp的高阶。 #include <cstdio> #include <cstring> #include <cmath&
按字母分类： ABCDEFGHIJKLMNOPQRSTUVWXYZ其他