【调试】crash使用方法

ptov address

btov 命令可以将一个物理地址转换成虚拟地址，在 BiscuitOS 中提供了一个实践案例用于介绍该命令的使用，其部署流程如下 (以 linux 5.0 X86_64 为例):

cd BiscuitOS
make linux-5.0-x86_64_defconfig
make menuconfig

  [*] Package  --->
      [*] CRASH and BUG Example  --->
          [*] Example: btov  --->

BiscuitOS/output/linux-5.0-x86_64/package/BiscuitOS-crash-btov

BiscuitOS-crash-btov Source Code

BiscuitOS 独立程序实践教程

实践例子为一个独立模块，在模块初始化函数 BiscuitOS_init() 内，分配了一个物理页和一个 PERCPU 变量，然后通过 page_address() 函数获得物理页对应的虚拟地址，接着使用 page_to_phys() 函数获得物理页对应的物理地址。对于 PERCPU 变量，alloc_percpu() 函数分配并返回了 PERCPU 变量的虚拟地址，并调用 virt_to_phys() 函数获得 PERCPU 变量对应的物理地址。将相应的值打印处理，并在函数执行过程中触发 PANIC 导致内核核心转储，并获得对应的内核核心转储文件. 接着在 BiscuitOS 上实践该案例，并使用 CRASH 进行调试:

在 BiscuitOS 上运行实例之前，先将 PANIC 的 OOPS 选项设置为 1，以免 OOPS 被 killed，具体命令 “sysctl -w kernel.panic_on_oops=1”. 接着加载模块 “BiscuitOS-crash-ptov-default.ko”, 此时触发内核核心转储，此时通过不同的方法获得内核核心转储文件，并对其进行分析:

从实践案例的 log 可以看出，物理页的物理地址地址是 0x1e24b000, 那么通过 btov 工具可以获得其虚拟地址是 0xffff8b82de24b000, 与 page_address() 返回的值一致; PERCPU 的物理地址是 0x97a1a0a04320，通过 ptov 工具转换之后虚拟地址是 0x232460a04320, 与 alloc_percpu() 函数返回的值一致. 因此 ptov 工具的转换结果完全正确.

ptov offset:cpuspec 通过 PERCPU 变量物理地址获得在指定 CPU 上的虚拟地址

用户进程或内核线程都有自己的地址空间，该地址空间称为线性地址空间，也称为虚拟地址空间，该空间的地址称为虚拟地址。系统硬件上具有的内存空间称为物理内存空间，该空间的地址称为物理地址。当内核真正访问或读写虚拟内存时，内核会对未分配物理内存的虚拟内存建立页表，以此保证用户进程使用自己的内存。PERCPU 变量是通过 PERCPU 分配器动态分配，或则静态方式定义，每个 CPU 都会有 PERCPU 变量的一个副本，因此 PERCPU 变量会在每个 CPU 上具有一个虚拟地址。PERCPU 变量的定义有如下方式:

static DEFINE_PER_CPU(struct struct_name, percpu_name);

struct struct_name \_\_percpu alloc_percpu(struct struct_name)

更多 PERCPU 变量以及 PERCPU 分配器，点击此链接

CRASH 提供了 ptob 工具可以建物理地址转换成虚拟地址，该转储可以针对内核转储文件，也可以针对正在运行的系统, 其中 “ptov offset:cpuspec” 用于将一个物理地址转换成虚拟地址，其命令格式如下:

ptov offset:cpuspec  a per-cpu offset with a CPU specifier:
                       :             CPU of the currently selected task.
                       :a[ll]        all CPUs.
                       :#[-#][,...]  CPU list(s), e.g. "1,3,5", "1-3",
                                     or "1,3,5-7,10".

对于 PERCPU 变量，其在每个 CPU 上都有副本，因此 PERCPU 在每个 CPU 上会具有不同的虚拟地址，ptov 命令可以便捷获得 PERCPU 在指定 CPU 或者全部 CPU 上的虚拟地址。当 cpuspec 空缺时，ptov 可以获得 PERCPU 变量在当前 CPU 上的虚拟地址; 当 cpuspec 为 a 或者为 all 时，那么 ptov 可以获得 PERCPU 在所有 CPU 上的虚拟地址。ptov 命令也支持获得 PERCPU 在某几个 CPU 上的虚拟地址。 在 BiscuitOS 中提供了一个实践案例用于介绍该命令的使用，其部署流程如下 (以 linux 5.0 X86_64 为例):

cd BiscuitOS
make linux-5.0-x86_64_defconfig
make menuconfig

  [*] Package  --->
      [*] CRASH and BUG Example  --->
          [*] Example: btov  --->

BiscuitOS/output/linux-5.0-x86_64/package/BiscuitOS-crash-btov

BiscuitOS-crash-btov Source Code

BiscuitOS 独立程序实践教程

实践例子为一个独立模块，在模块初始化函数 BiscuitOS_init() 内，分配了一个物理页和一个 PERCPU 变量，然后通过 page_address() 函数获得物理页对应的虚拟地址，接着使用 page_to_phys() 函数获得物理页对应的物理地址。对于 PERCPU 变量，alloc_percpu() 函数分配并返回了 PERCPU 变量的虚拟地址，并调用 virt_to_phys() 函数获得 PERCPU 变量对应的物理地址。将相应的值打印处理，并在函数执行过程中触发 PANIC 导致内核核心转储，并获得对应的内核核心转储文件. 接着在 BiscuitOS 上实践该案例，并使用 CRASH 进行调试:

在 BiscuitOS 上运行实例之前，先将 PANIC 的 OOPS 选项设置为 1，以免 OOPS 被 killed，具体命令 “sysctl -w kernel.panic_on_oops=1”. 接着加载模块 “BiscuitOS-crash-ptov-default.ko”, 此时触发内核核心转储，此时通过不同的方法获得内核核心转储文件，并对其进行分析:

从实践案例的 log 可以看出，PERCPU 的物理地址是 0x97a1a0a04320，通过 ptov 工具转换查看该 PERCPU 在所有 CPU 上的虚拟地址，可以看出 CPU 0 上的虚拟地址是 0x23247fc04320, 而在 CPU 1 上的虚拟地址是 0x23247fd04320. 接着将命令格式中的 cpuspec 设置为其他值进行查看.

vtop <address> 将一个虚拟地址转换成物理地址

进程的地址空间分为两部分，一部分是进程使用的用户虚拟地址空间，另外一部分是内核使用的虚拟地址空间。用户空间的的虚拟地址只有与物理内存建立页表之后才能进行使用，通常页表时在对虚拟地址访问发生缺页时建立。CRASH 提供的 vtop 工具通过可以基于页表等信息将一个虚拟地址转换成物理地址，并输出 VMA 和各级页表的值，以及 PTE 页表内容。该命令的格式如下:

crash> vtop address

当 vtop 使用上面的命令在转换一个虚拟地址时，vtop 会基于当前进程自动判断该地址是内核空间虚拟地址还有用户空间虚拟地址，如果页表存在，那么 vtop 就会输出上图的内容，首先是虚拟地址和物理地址的内容，接着是 PGD/PMD/PTE/PAGE 的地址以及内容，然后是 PTE 页表的内容、PTE 包含的物理地址以及 PTE 页表的置位信息。vtop 还输出了包含当前进程包含该虚拟地址的 struct vm_area_struct 的地址、起始和结束地址、VMA 的 flags 信息、以及 VMA 对应的文件信息。vtop 最后还会输出物理地址对应的物理页信息，包含了物理页 struct page 的地址、物理地址、物理页所在的 NUMA NODE 等信息. 当当前进程的虚拟地址没有绑定物理内存，那么 vtop 将显示该虚拟地址没有被访问过:

vtop -u <address> 将一个用户空间的虚拟地址转换成物理地址

进程的地址空间分为两部分，一部分是进程使用的用户虚拟地址空间，另外一部分是内核使用的虚拟地址空间。用户空间的的虚拟地址只有与物理内存建立页表之后才能进行使用，通常页表时在对虚拟地址访问发生缺页时建立。CRASH 提供的 vtop 工具通过可以基于页表等信息将一个虚拟地址转换成物理地址，并输出 VMA 和各级页表的值，以及 PTE 页表内容。该命令的格式如下:

crash> vtop -u address

当 vtop 使用上面的命令在转换一个用户空间虚拟地址时，如果页表存在，那么 vtop 就会输出上图的内容，首先是虚拟地址和物理地址的内容，接着是 PGD/PMD/PTE/PAGE 的地址以及内容，然后是 PTE 页表的内容、PTE 包含的物理地址以及 PTE 页表的置位信息。vtop 还输出了包含当前进程包含该虚拟地址的 struct vm_area_struct 的地址、起始和结束地址、VMA 的 flags 信息、以及 VMA 对应的文件信息。vtop 最后还会输出物理地址对应的物理页信息，包含了物理页 struct page 的地址、物理地址、物理页所在的 NUMA NODE 等信息. 当当前进程的虚拟地址没有绑定物理内存，那么 vtop 将显示该虚拟地址没有被访问过:

在 BiscuitOS 中提供了一个实践案例用于介绍该命令的使用，其部署流程如下 (以 linux 5.0 X86_64 为例):

cd BiscuitOS
make linux-5.0-x86_64_defconfig
make menuconfig

  [*] Package  --->
      [*] CRASH and BUG Example  --->
          [*] Example: vtop translate user address  --->

BiscuitOS/output/linux-5.0-x86_64/package/BiscuitOS-crash-vtop-user-address-default

BiscuitOS-crash-vtop-user-address-default Source Code

BiscuitOS 独立程序实践教程

实践例子为一个应用程序，在 main() 函数内，程序从 malloc() 分配一段虚拟内存，在打印该虚拟内容之后程序进程死循环，以此获得内核核心转储文件。接着在 BiscuitOS 上实践该案例，并使用 CRASH 进行调试:

在 BiscuitOS 上运行实例之前，先将 PANIC 的 OOPS 选项设置为 1，以免 OOPS 被 killed，具体命令 “sysctl -w kernel.panic_on_oops=1”. 接着运行应用程序 BiscuitOS-crash-vtop-user-address-default, 此时程序进入死循环，此时通过不同的方法获得内核核心转储文件，并对其进行分析:

从实践案例运行情况可知，进程获得的虚拟地址是 0x55f151853260, 那么使用 vtop 查看 0x55f151853260 对应的物理地址，当使用 “vtop -u 0x55f151853260” 进行查询，结果显示虚拟地址没有被访问过，那时因为当前进程是 CPU 0 上的 “swapper/1” 进程，那么此时使用 “-c” 选项绑定到 BiscuitOS-crash-vtop-user-address-default 进程，此时使用命令 “vtop -u 0x55f151853260 -c 1123”, 此时可以到所需的各种信息.

vtop -k <address> 将一个内核空间的虚拟地址转换成物理地址

进程的地址空间分为两部分，一部分是进程使用的用户虚拟地址空间，另外一部分是内核使用的虚拟地址空间。对于内核空间的虚拟地址，所有进程看到的都是一致的，另外内核空间的虚拟地址划分为多个区域，例如 VMALLOC 区域、PKMAP 区域、FIXMAP 区域、线性映射区域等，在每个区域中虚拟地址可能已经与物理地址建立好页表可以直接访问，有的区域则需要动态分配并动态建立页表。CRASH 提供的 vtop 工具通过可以基于页表等信息将一个内核空间的虚拟地址转换成物理地址，并输出页表以及 PTE 页表内容。该命令的格式如下:

crash> vtop -k address

当 vtop 使用上面的命令转换一个内核空间的虚拟地址时，如果页表存在，那么 vtop 将输出虚拟地址和物理地址的信息、PGD/PMD/PTE 页表的地址和内容，并输出 PTE 页表的具体内容，最后输出物理页的信息。如果一个虚拟地址不是内核地址，那么 vtop 将进行提示:

在 BiscuitOS 中提供了一个实践案例用于介绍该命令的使用，其部署流程如下 (以 linux 5.0 X86_64 为例):

cd BiscuitOS
make linux-5.0-x86_64_defconfig
make menuconfig

  [*] Package  --->
      [*] CRASH and BUG Example  --->
          [*] Example: vtop translate kernel address  --->

BiscuitOS/output/linux-5.0-x86_64/package/BiscuitOS-crash-vtop-kernel-address-default

BiscuitOS-crash-vtop-kernel-address-default Source Code

BiscuitOS 独立程序实践教程

实践例子为一个独立模块，在模块的初始化函数 BiscuitOS_init() 内，模块从 kmalloc() 函数申请了一段内存，并通过 virt_to_phys() 函数获得对应的物理地址，并将两个地址都打印出来。在打印内容之后程序触发 PANIC，以此获得内核核心转储文件。接着在 BiscuitOS 上实践该案例，并使用 CRASH 进行调试:

在 BiscuitOS 上运行实例之前，先将 PANIC 的 OOPS 选项设置为 1，以免 OOPS 被 killed，具体命令 “sysctl -w kernel.panic_on_oops=1”. 接着加载内核模块 BiscuitOS-crash-vtop-kernel-address-default.ko，此时通过不同的方法获得内核核心转储文件，并对其进行分析:

从实践的 log 可以看出，分配的虚拟地址是 0xffff9eee9ee12410, 其对应的物理地址是 0x1ee12410, 此时使用 vtop 进行转换，可以看到虚拟地址和物理地址与程序运行的一致。另外还可以获得内核虚拟地址对应的 PGD/PUD/PMD/PTE 页表的地址与内容，并打印了 PTE 页表位图信息，最后还打印了物理地址和物理页的信息。

vtop -c pid <address> 将某个进程的虚拟地址转换成物理地址

进程的地址空间分为两部分，一部分是进程使用的用户虚拟地址空间，另外一部分是内核使用的虚拟地址空间。用户空间的的虚拟地址只有与物理内存建立页表之后才能进行使用，通常页表时在对虚拟地址访问发生缺页时建立。CRASH 提供的 vtop 工具可以基于不同的进程将一个用户空间的虚拟地址转换成物理地址。该命令的格式如下:

crash> vtop -c pid -u address

当 vtop 使用上面的命令在转换一个用户空间指定进程的虚拟地址时，如果页表存在，那么 vtop 就会输出上图的内容，首先是虚拟地址和物理地址的内容，接着是 PGD/PMD/PTE/PAGE 的地址以及内容，然后是 PTE 页表的内容、PTE 包含的物理地址以及 PTE 页表的置位信息。vtop 还输出了包含指定进程包含该虚拟地址的 struct vm_area_struct 的地址、起始和结束地址、VMA 的 flags 信息、以及 VMA 对应的文件信息。vtop 最后还会输出物理地址对应的物理页信息，包含了物理页 struct page 的地址、物理地址、物理页所在的 NUMA NODE 等信息. 当指定进程的虚拟地址没有绑定物理内存，那么 vtop 将显示该虚拟地址没有被访问过:

在 BiscuitOS 中提供了一个实践案例用于介绍该命令的使用，其部署流程如下 (以 linux 5.0 X86_64 为例):

cd BiscuitOS
make linux-5.0-x86_64_defconfig
make menuconfig

  [*] Package  --->
      [*] CRASH and BUG Example  --->
          [*] Example: vtop translate user address with PID --->

BiscuitOS/output/linux-5.0-x86_64/package/BiscuitOS-crash-vtop-pid-user-address-default

BiscuitOS-crash-vtop-pid-user-address-default Source Code

BiscuitOS 独立程序实践教程

实践例子为一个应用程序，通过匿名共享映射的方式分配了一段虚拟内存，并对虚拟内存进行写操作，最后打印写入的虚拟内存地址和对应的值。在打印该虚拟内容之后程序进程死循环，以此获得内核核心转储文件。接着在 BiscuitOS 上实践该案例，并使用 CRASH 进行调试:

在 BiscuitOS 上运行实例之前，先将 PANIC 的 OOPS 选项设置为 1，以免 OOPS 被 killed，具体命令 “sysctl -w kernel.panic_on_oops=1”. 接着以压后台的方式多次运行应用程序 BiscuitOS-crash-vtop-pid-user-address-default, 此时程序进入死循环，此时通过不同的方法获得内核核心转储文件，并对其进行分析:

从实践案例运行情况可以，BiscuitOS-crash-vtop-pid-user-address-default 程序运行了 5 次，每次获得的虚拟地址都是 0x8000000000, 此时首先在 CRASH 中通过 ps 命令查看进程的 PID，然后使用 vtop 命令查看 0x8000000000 对应的物理内存。上图实例中查看了 PID 为 1124 和 1126 的进程，虽然虚拟地址相同，但物理地址却不相同。因此该命令可以很便捷的获得指定进程的虚拟地址到物理地址映射信息.

vtop -c taskp <address> 将某个进程的虚拟地址转换成物理地址

进程的地址空间分为两部分，一部分是进程使用的用户虚拟地址空间，另外一部分是内核使用的虚拟地址空间。用户空间的的虚拟地址只有与物理内存建立页表之后才能进行使用，通常页表时在对虚拟地址访问发生缺页时建立。CRASH 提供的 vtop 工具可以基于不同的进程将一个用户空间的虚拟地址转换成物理地址。该命令的格式如下:

crash> vtop -c taskp -u address

当 vtop 使用上面的命令在转换一个用户空间指定进程的虚拟地址时，如果页表存在，那么 vtop 就会输出上图的内容，首先是虚拟地址和物理地址的内容，接着是 PGD/PMD/PTE/PAGE 的地址以及内容，然后是 PTE 页表的内容、PTE 包含的物理地址以及 PTE 页表的置位信息。vtop 还输出了包含指定进程包含该虚拟地址的 struct vm_area_struct 的地址、起始和结束地址、VMA 的 flags 信息、以及 VMA 对应的文件信息。vtop 最后还会输出物理地址对应的物理页信息，包含了物理页 struct page 的地址、物理地址、物理页所在的 NUMA NODE 等信息. 当指定进程的虚拟地址没有绑定物理内存，那么 vtop 将显示该虚拟地址没有被访问过:

在 BiscuitOS 中提供了一个实践案例用于介绍该命令的使用，其部署流程如下 (以 linux 5.0 X86_64 为例):

cd BiscuitOS
make linux-5.0-x86_64_defconfig
make menuconfig

  [*] Package  --->
      [*] CRASH and BUG Example  --->
          [*] Example: vtop translate user address with PID --->

BiscuitOS/output/linux-5.0-x86_64/package/BiscuitOS-crash-vtop-pid-user-address-default

BiscuitOS-crash-vtop-pid-user-address-default Source Code

BiscuitOS 独立程序实践教程

实践例子为一个应用程序，通过匿名共享映射的方式分配了一段虚拟内存，并对虚拟内存进行写操作，最后打印写入的虚拟内存地址和对应的值。在打印该虚拟内容之后程序进程死循环，以此获得内核核心转储文件。接着在 BiscuitOS 上实践该案例，并使用 CRASH 进行调试:

在 BiscuitOS 上运行实例之前，先将 PANIC 的 OOPS 选项设置为 1，以免 OOPS 被 killed，具体命令 “sysctl -w kernel.panic_on_oops=1”. 接着以压后台的方式多次运行应用程序 BiscuitOS-crash-vtop-pid-user-address-default, 此时程序进入死循环，此时通过不同的方法获得内核核心转储文件，并对其进行分析:

从实践案例运行情况可以，BiscuitOS-crash-vtop-pid-user-address-default 程序运行了 5 次，每次获得的虚拟地址都是 0x8000000000, 此时首先在 CRASH 中通过 ps 命令查看进程的进程描述符，然后使用 vtop 命令查看 0x8000000000 对应的物理内存。上图实例中查看了进程描述符为 ffff98ca5e539b00 和 ffff98ca5e53de80 的进程，虽然虚拟地址相同，但物理地址却不相同。因此该命令可以很便捷的获得指定进程的虚拟地址到物理地址映射信息.

vm 获得当前进程用户空间的虚拟区域信息

用户进程的地址空间有多个区域组成，这些区域称为虚拟区域 VMA。每个 VMA 维护了一段虚拟内存，并用于指定的任务，例如用于存储进程代码段的 VMA、用于存储进程数据的 VMA 等。CRASH 提供了 vm 命令可以获得当前 CPU 上运行进程的用户进程虚拟区域信息，其命令格式如下:

crash> vm

vm 命令之后没有跟任何参数，这个时候就读取当前 CPU 上运行的进程的虚拟区域信息。CRASH vm 命令将展示一下信息:

• PID 进程 ID
• TASK 进程描述符 struct task_struct 的虚拟地址
• CPU 当前 CPU ID
• COMMAND 当前进程运行的命令名字命令名字
• MM 进程地址空间描述符 struct mm_struct 的地址
• PGD 进程 PGD 页表入口的地址
• RSS 进程使用物理内存的数量
• TOTAL_VM 进程占用的虚拟内存数量
• VMA 虚拟区域的描述符 struct vm_area_struct 的虚拟地址
• START 虚拟区域的起始地址
• END 虚拟区域的结束地址
• FLAGS 虚拟区域标志
• FILE 虚拟区域映射的文件

如果当前 CPU 上运行的是内核线程，那么内核线程不包含任何用户空间虚拟内存的信息，其展示信息如下:

vm pid 通过进程 ID 获得指定进程用户空间的虚拟区域信息

用户进程的地址空间有多个区域组成，这些区域称为虚拟区域 VMA。每个 VMA 维护了一段虚拟内存，并用于指定的任务，例如用于存储进程代码段的 VMA、用于存储进程数据的 VMA 等。CRASH 提供了 vm 命令可以通过进程 ID 获得指定进程的虚拟区域信息，其命令格式如下:

crash> vm pid

vm 命令之后跟随进程描述符地址，这个时候将输出指定进程的用户空间虚拟区域信息。CRASH vm 命令将展示一下信息:

• PID 进程 ID
• TASK 进程描述符 struct task_struct 的虚拟地址
• CPU 当前 CPU ID
• COMMAND 当前进程运行的命令名字命令名字
• MM 进程地址空间描述符 struct mm_struct 的地址
• PGD 进程 PGD 页表入口的地址
• RSS 进程使用物理内存的数量
• TOTAL_VM 进程占用的虚拟内存数量
• VMA 虚拟区域的描述符 struct vm_area_struct 的虚拟地址
• START 虚拟区域的起始地址
• END 虚拟区域的结束地址
• FLAGS 虚拟区域标志
• FILE 虚拟区域映射的文件

如果 pid 对应的 TASK 是一个内核线程，那么内核线程不包含任何用户空间虚拟内存的信息，其展示信息如下:

vm taskp 通过进程描述符获得进程用户空间虚拟区域信息

用户进程的地址空间有多个区域组成，这些区域称为虚拟区域 VMA。每个 VMA 维护了一段虚拟内存，并用于指定的任务，例如用于存储进程代码段的 VMA、用于存储进程数据的 VMA 等。CRASH 提供了 vm 命令可以通过进程描述符获得指定进程的虚拟区域信息，其命令格式如下:

crash> vm taskp

vm 命令之后跟随进程描述符地址，这个时候将输出指定进程的用户空间虚拟区域信息。CRASH vm 命令将展示一下信息:

• PID 进程 ID
• TASK 进程描述符 struct task_struct 的虚拟地址
• CPU 当前 CPU ID
• COMMAND 当前进程运行的命令名字命令名字
• MM 进程地址空间描述符 struct mm_struct 的地址
• PGD 进程 PGD 页表入口的地址
• RSS 进程使用物理内存的数量
• TOTAL_VM 进程占用的虚拟内存数量
• VMA 虚拟区域的描述符 struct vm_area_struct 的虚拟地址
• START 虚拟区域的起始地址
• END 虚拟区域的结束地址
• FLAGS 虚拟区域标志
• FILE 虚拟区域映射的文件

如果 taskp 对应的 TASK 是一个内核线程，那么内核线程不包含任何用户空间虚拟内存的信息，其展示信息如下:

vm -p 打印进程所有虚拟区域到物理内存的映射关系

用户进程的地址空间有多个区域组成，这些区域称为虚拟区域 VMA。每个 VMA 维护了一段虚拟内存，并用于指定的任务，例如用于存储进程代码段的 VMA、用于存储进程数据的 VMA 等。VMA 可以映射一段物理内存，也可能映射一段文件，CRASH 提供了 vm 可以打印进程所有虚拟区域的映射关系，这个映射关系包括虚拟内存到物理内存的映射关系，也可能是虚拟地址到映射文件的映射关系，具体命令格式如下:

crash> vm -p

vm 命令之后跟上 “-p” 选项之后，CRASH 将打印当前 CPU 上进程的所有虚拟区域的映射关系。如果想打印某个进程的虚拟区域映射关系，可以在命令之后添加进程的 PID 或者进程描述符 taskp. CASH vm 命令将展示一下信息:

• PID 进程 ID
• TASK 进程描述符 struct task_struct 的虚拟地址
• CPU 当前 CPU ID
• COMMAND 当前进程运行的命令名字命令名字
• MM 进程地址空间描述符 struct mm_struct 的地址
• PGD 进程 PGD 页表入口的地址
• RSS 进程使用物理内存的数量
• TOTAL_VM 进程占用的虚拟内存数量
• VMA 虚拟区域的描述符 struct vm_area_struct 的虚拟地址
• START 虚拟区域的起始地址
• END 虚拟区域的结束地址
• FLAGS 虚拟区域标志
• FILE 虚拟区域映射的文件

如果 taskp 对应的 TASK 是一个内核线程，那么内核线程不包含任何用户空间虚拟内存的信息，其展示信息如下:

在显示每个 VMA 的时候，如果 VMA 映射的是物理内存，那么 CRASH 将打印该虚拟区域内已经映射物理内存的虚拟区域信息，该信息包括虚拟区域的描述符 vmap、虚拟区域的起始地址和结束地址、虚拟区域的标志，最后包括已经映射物理内存的虚拟地址和映射的物理地址. 如果虚拟地址映射的物理内存被交换到 SWAP 空间，那么会显示 SWAP 空间的位置和 sWAP entry 信息。例如下图:

在显示每个 VMA 的时候，如果 VMA 映射的是文件，那么 CRASH 将打印虚拟区域的描述符地址 vmap、虚拟区域的起始地址和结束地址、虚拟区域的标志、以及虚拟区域映射的文件。接着 CRASH 将打印虚拟地址映射文件的偏移信息:

vm -P 打印进程的指定虚拟区域到物理内存的映射关系

用户进程的地址空间有多个区域组成，这些区域称为虚拟区域 VMA。每个 VMA 维护了一段虚拟内存，并用于指定的任务，例如用于存储进程代码段的 VMA、用于存储进程数据的 VMA 等。VMA 可以映射一段物理内存，也可能映射一段文件，CRASH 提供了 vm 可以打印进程所有虚拟区域的映射关系，这个映射关系包括虚拟内存到物理内存的映射关系，也可能是虚拟地址到映射文件的映射关系，与 “vm -p” 命令类似， “vm -p” 显示指定进程所有 VMA 的映射关系，这对于查找指定的 VMA 区域不太友好。CRASH vm 提供了 “-P” 可以查看指定 VMA 的映射关系，具体命令格式如下:

crash> vm -P VMAp

vm 命令之后跟上 “-P VMAp” 选项之后，CRASH 将打印当前 CPU 上进程 VMAp 对应的虚拟区域的映射关系。如果想打印某个进程的虚拟区域映射关系，可以在命令之后添加进程的 PID 或者进程描述符 taskp. CASH vm 命令将展示一下信息:

• PID 进程 ID
• TASK 进程描述符 struct task_struct 的虚拟地址
• CPU 当前 CPU ID
• COMMAND 当前进程运行的命令名字命令名字
• MM 进程地址空间描述符 struct mm_struct 的地址
• PGD 进程 PGD 页表入口的地址
• RSS 进程使用物理内存的数量
• TOTAL_VM 进程占用的虚拟内存数量
• VMA 虚拟区域的描述符 struct vm_area_struct 的虚拟地址
• START 虚拟区域的起始地址
• END 虚拟区域的结束地址
• FLAGS 虚拟区域标志
• FILE 虚拟区域映射的文件

如果 taskp 对应的 TASK 是一个内核线程，那么内核线程不包含任何用户空间虚拟内存的信息，其展示信息如下:

在显示指定 VMA 的时候，如果 VMA 映射的是物理内存，那么 CRASH 将打印该虚拟区域内已经映射物理内存的虚拟区域信息，该信息包括虚拟区域的描述符 vmap、虚拟区域的起始地址和结束地址、虚拟区域的标志，最后包括已经映射物理内存的虚拟地址和映射的物理地址. 如果虚拟地址映射的物理内存被交换到 SWAP 空间，那么会显示 SWAP 空间的位置和 sWAP entry 信息。例如下图:

在显示每个 VMA 的时候，如果 VMA 映射的是文件，那么 CRASH 将打印虚拟区域的描述符地址 vmap、虚拟区域的起始地址和结束地址、虚拟区域的标志、以及虚拟区域映射的文件。接着 CRASH 将打印虚拟地址映射文件的偏移信息:

vm -m 打印用户进程的地址描述符 struct mm_struct 内容

用户进程的地址空间通过地址空间描述符进行描述，其通过 struct mm_struct 进行管理。地址空间描述符记录了进程的虚拟内存信息、页表、VMA 等多种信息，对分析进程的行为有很大的帮助。CRASH 提供了 “ps” 命令可以打印进程描述符，但不能直观的给出进程的地址描述符，因此 CRASH 提供了 “vm -m” 命令可以将指定进程的地址描述符内容打印出来。具体命令格式如下:

crash> vm -m

vm 命令之后跟上 “-m” 选项之后，CRASH 将打印当前进程的地址描述符信息，如果需要打印指定进程的地址描述符，那么可以跟上进程 PID 信息。CRASH vm 命令将展示以下信息:

• PID 进程 ID
• TASK 进程描述符 struct task_struct 的虚拟地址
• CPU 当前 CPU ID
• COMMAND 当前进程运行的命令名字命令名字
• struct mm_struct 内容

如果 PID 对应的 TASK 是一个内核线程，那么内核线程不包含用户进程地址空间:

vm -R 在用户进程虚拟内容找查找信息

用户进程的地址空间有多个区域组成，这些区域称为虚拟区域 VMA。每个 VMA 维护了一段虚拟内存，并用于指定的任务，例如用于存储进程代码段的 VMA、用于存储进程数据的 VMA 等。CRASH 提供 vm 命令可以打印进程虚拟内存相关的信息，但信息特别复杂，那么 CRASH 提供了 “vm -R” 选项可以在进程的虚拟内存信息中查找包含内容，具体命令格式如下:

crash> vm -R <reference>

vm 命令之后跟上 “-R” 和要查找的内容，那么 CRASH 将输出当前进程虚拟地址信息中包含指定内容的地方。如果想在指定进程的虚拟内存信息中查找，可以在命令之后添加进程的 PID 信息. 其输出的信息包括:

• PID 进程 ID
• TASK 进程描述符 struct task_struct 的虚拟地址
• CPU 当前 CPU ID
• COMMAND 当前进程运行的命令名字命令名字
• MM 进程地址空间描述符 struct mm_struct 的地址
• PGD 进程 PGD 页表入口的地址
• RSS 进程使用物理内存的数量
• TOTAL_VM 进程占用的虚拟内存数量
• VMA 虚拟区域的描述符 struct vm_area_struct 的虚拟地址
• START 虚拟区域的起始地址
• END 虚拟区域的结束地址
• FLAGS 虚拟区域标志
• FILE 虚拟区域映射的文件

vm -R filename 命令可以查找映射了文件 libc-2.27.so 的 VMA 信息

vm -R vaddr 命令可以查找进程包含虚拟地址的 VMA 信息:

vm -R flags 命令可以查找 VMA Flags 为指定值的 VMA 信息:

vm -R phys 命令可以查找映射该物理地址的虚拟地址信息:

vm -R vmap 命令 vmap 的虚拟区域信息:

vm -v 打印进程所有 VMA 描述符内容

用户进程的地址空间有多个区域组成，这些区域称为虚拟区域 VMA。每个 VMA 维护了一段虚拟内存，并用于指定的任务，例如用于存储进程代码段的 VMA、用于存储进程数据的 VMA 等。内核使用 struct vm_area_struct 结构体描述一个 VMA，CRASH vm 提供了命令可以将用户进程所有的虚拟区域描述符的内容打印出来，具体命令如下:

crash> vm -v

vm 命令之后跟上 “-v” 选项之后，CRASH 将打印当前 CPU 上进程的所有虚拟区域描述符的内容，如果想查找指定进程的话，可以在命令之后跟上进程的 PID 或者 taskp 内容。此时可以使用 CRASH 提供的 struct 命令查看 struct vm_area_struct 结构体定义.

vm -f 解码虚拟区域标志

用户进程的地址空间有多个区域组成，这些区域称为虚拟区域 VMA。每个 VMA 维护了一段虚拟内存，并用于指定的任务，例如用于存储进程代码段的 VMA、用于存储进程数据的 VMA 等。内核使用 struct vm_area_struct 结构体描述一个 VMA，每个虚拟区域都有不同的属性，有的可读、有的可行、有的可执行等，这些标志通过虚拟区域标志集合进行维护。CRASH 提供了 “vm -f” 命令用于将虚拟区域标志集合转换为字符串形式，以便使用。具体命令如下:

crash> vm -f <flags>

• READ: PROT_READ VMA 可读
• WRITE: PROT_WRITE VMA 可写
• EXEC: PROT_EXEC VMA 可执行
• SHARED: MAP_SHARED VMA 共享映射
• MAYREAD: MAY_READ VMA 也许可读
• MAYWRITE: MAY_WRITE VMA 也许可写
• MAYEXEC: MAY_EXEC VMA 也许可写
• MAYSHARE: VMA 也许是共享映射
• GROWDOWN: PROT_GROWSDOWN VMA 向下生长
• NOHUGEPAGE: MADV_NOHUGEPAGE 非大页映射
• PFNMAP: VM_PFNMAP PFN 映射，没有 struct page.
• DENYWRITE: 禁止写入
• EXECUTABLE: 可执行的
• LOCKED: VM_LOCKED VMA 被锁住了
• IO: VM_IO IO 映射
• SEQ_READ: 串行读

vm -d/-x 输出内容格式控制

当使用 CRASH 提供的 vm 命令查看虚拟区域描述符或者地址空间描述符的时候，为了方便查看，CRASH vm 命令提供了输出格式选项，其中 “-d” 选项以十进制方式输出内容、”-x” 选项以十六进制方式输出内容:

pte <conteents> 解码 PTE 内容

虚拟内存与物理内存之间通过页表进行映射，在有的架构中页表有两级页表，分别是 PGD/PTE，有的有三级页表 PGD/PMD/PTE, 有的有四级页表 PGD/PUD/PMD/PTE, 有的架构有五级页表 PGD/P4D/PUD/PMD/PTE. 无论几级页表，在页大小都是 4KiB 的情况下，最后一级页表都是 PTE。CRASH 提供了 pte 命令用来解码 PTE 页表项中的内容，其命令格式如下:

crash> pte content

CRASH 提供的 pte 命令将一个十六进制的 PTE 页表内容进行解码，解码之后可以获得 PTE 对应的物理页以及 PTE 页表的标志。如果 PTE 对应的物理页表位于 SWAP 中，那么 CRASH 将输出物理页在 SWAP 中偏移以及 SWAP 的设备名.

Crash 打印表达式的值

当使用 CRASH 分析内核转储文件时，需要查看某些变量或者表达式的值，CRASH 提供了 “p” 命令，该命令类似 print 的作用，将会打印变量的值，这对问题的分析起到了很大的作用。该命令格式如下:

# SYNOPSIS
p [-x|-d][-u] [expression | symbol[:cpuspec]]

本节以手动触发 Panic 为例进行实践讲解。在 BiscuitOS 上通过输入 “echo c > /proc/sysrq-trigger” 来触发内核崩溃，并对转储文件为例进行分析:

p symobl 打印符号的值

CRASH 提供的 “p symbol” 命令可以打印 symbol 的值，这里值得注意的是如果 symbol 的范围，目前支持全局导出的 symbol。具体系统导出的 symobl 可以在内核源码的生成的 System.map 里获得。

”p symbol” 命令执行之后将会输出 symbol 的值，如果 symbol 是一个变量，那么就输出变量的值; 如果 symbol 是一个结构体或联合体，那么就输出其内容; 如果 symbol 是一个 PERCPU 变量，那么将打印 PERCPU 变量在所有 CPU 上的值。

p symbol:cpuspec 打印 PERCPU 变量的值

CRASH 提供的 p symbol:cpuspec命令可以用于打印 PERCPU 变量，众所周知 PERCPU 变量在每个 CPU 上都有一个副本，那么该命令正好可以打印 PERCPU 变量在指定 CPU 上的值，也可以打印所有 CPU 上的值，其命令格式如下:

p symbol:cpuspec  CPU specification for a per-cpu symbol:
                  :             CPU of the currently selected task.
                  :a[ll]        all CPUs.
                  :#[-#][,...]  CPU list(s), e.g. "1,3,5", "1-3",
                                or "1,3,5-7,10".

对于 PERCPU 变量 irq_stat, 通过 p 命令打印了其在 CPU 1 上的值.

px/pd 以十六进制/十进制方式输出

CRASH 提供的 “p symbol” 命令可以打印 symbol 的值，在输出值的时候，p 命令提供了 “x/u” 的选择，以此按十进制或十六进制的方式输出。其中 x 表示按十六进制的方式输出，u 表示按十进制的方式输出。

Crash 内存读写

当使用 CRASH 分析内存转储文件时，有时需要对进程的虚拟内存进行读写操作、有时需要对物理内存进行读写操作，那么为了满足这方面的需求，CRASH 提供了相应的命令满足需求，具体命令如下:

# SYNOPSIS
  rd [-adDsSupxmfNR][-8|-16|-32|-64][-o offs][-e addr][-r file][address|symbol][count]

  wr [-u|-k|-p] [-8|-16|-32|-64] [address|symbol] value

rd -p <address> 读取物理地址的内容

CRASH rd -p 命令用于读取物理地址对应的的内容，其中 “address” 参数是一个物理地址。在 Linux 系统中，可以使用 “cat /proc/iomem” 查看系统的物理内存信息，以此便于物理内存的查看:

不是所有的物理内存都可以读，Crash rd -p 命令只对 Reserved(0x00000000)、System RAM(0x00001000)、Video ROM(0x000c0000)、Adaptor ROM(0x000c9800) 的物理地址是可读取内容的。

Crash rd -p 命令对于 PCI Bus(0x000a0000)、IOAPIC(0xfec00000)、HPET(0xfed00000)、Local APIC(0xfee00000) 对应的 IO 物理地址是不可读的.

rd -u <addresss> 读取虚拟地址的内容

CRASH rd 命令用于读取虚拟地址对应的内容。在 Linux 中虚拟内存主要分作两部分，一部分为进程的用户空间，另外一部分为内核的虚拟空间。

对于所有进程来说内核虚拟空间都是一致的，而用户空间则是进程独占的。CRASH rd address 参数默认假设为内核空间的虚拟地址，因此在使用该命令查看用户进程的虚拟地址时需要显示的加上 “-u” 参数说明该地址是一个用户空间虚拟地址。

另外当使用该命令查看用户进程的虚拟地址时需要指定进程，而内核虚拟空间的虚拟地址则不需指定进程。

rd [-dDx][-8][-16][-32][-64][-a] <address> 格式化输出物理地址内容

CRASH 在使用 rd 命令输出物理内存的内容时，可使用格式化参数来控制输出内容的格式

• -d 以十进制的方式输出
• -D 以无符号十进制方式输出
• -x 以十六进制方式输出
• -8 按 8-bit 长度进程输出
• -16 按 16-bit 长度进行输出
• -32 按 32-bit 长度进行输出
• -64 按 64-bit 长度进行输出
• -a 以 ASCII 方式进行输出

rd -s <address> 读取物理内存中符号引用

CRASH rd 命令提供了 “-s” 选项，该选项将物理内存中符号引用的内容打印出来. 例如 rd 打印的物理内存正好是进程的堆栈区域，那么该选项就会将函数调用栈给打印处理，从中可以看出物理内存对应的函数调用关系.

rd -S <address> 读取物理内存中 SLAB cache 的引用

CRASH rd 命令提供了 “-S” 选项，该选项可以将物理内存中作为 SLAB cache 的引用进行输出，通过该命令可以便捷查看 SLAB cache 的地址。

rd -SS <address> 读取物理内存中 SLAB cache 的引用和内容

CRASH rd 命令提供了 “-SS” 选项，与 “-S” 相比，”-SS” 选项不仅输出了物理内存中作为 SLAB cache 的引用，还输出了对应物理内存的内容。

rd <symbol> 读取符号所在物理内存的内容

CRASH 通过 rd 命令可以读取 symbol 对应物理内存的值，可用的符号可以通过 System.map 获得。

rd <address> count 读取一定数量物理内存的内容

CRASH 的 rd 命令的 count 选项可以控制读取物理内存的数量。默认情况下，rd 命令的 count 为 1，并且最右边输出 ASCII 的内容。

rd <address> -o offset 读取起始物理地址偏移处的内容

CRASH rd 命令提供了 “-o offset” 选项，该选项用于读取起始物理地址偏移 offset 处的内容.

rd <addr0> -e <addr1> 读取物理内存 addr0 到 addr1 之间的内容

CRASH rd 命令提供了 “-e address” 选项，该选项可以打印起始物理地址到 address 物理地址之间的内容。当该命令不可以与 “count” 选项共同使用.

Crash 模块分析

当使用 CRASH 分析内核转储文件时，有时需要对内核模块进行分析，由于内核模块一般独立于源码树之外编译，因此模块的符号表和调试信息在内核转储文件中不存在，因此无法直接对内核模块进行调试。CRASH 提供了 mod 命令可以动态加载模块的调试信息和符号表，这位于模块中的问题定位提供了有力的帮助。具体命令如下:

# SYNOPSIS
  mod -s module [objfile] | -d module | -S [directory] [-D|-t|-r|-R|-o|-g]

在使用 CRASH 调试模块之前，需要确保内核的 CONFIG_KALLSYMS 宏已经打开，已经模块编译的时候带上了 -g 标志 (例如在模块的 Makefile 中添加如下代码):

mod -s <module> [objectfile] 加载模块的符号表和 debuginfo

在使用 CRASH 分析模块的时候，由于模块的符号表和 debuginfo 的内容不包含在内核转储文件中，因此在分析模块文件之间需要先将这些信息导入到 CRASH 中，CRASH mod 命令提供了 “-s” 选项，该选项的命令格式如下:

mod -s module [objfile]

在 mod 命令的 “-s” 选项中，module 为模块的名字，objfile 为模块对应的目标文件, 值得注意的是 module 必须是一个模块名字，该命令可以通过 lsmod 进行查看，否则模块名字不对将被认为非法模块。

objfile 选项如果存在，那么需要给出 object 的绝对路径。当 object 选项不存在的时候，该命令用于查询模块的目标文件。

接下来通过一个实践例子进行理解该命令的使用. 在 BiscuitOS 中提供了一个实践案例用于介绍该命令的使用，其部署流程如下 (以 linux 5.0 X86_64 为例):

cd BiscuitOS
make linux-5.0-x86_64_defconfig
make menuconfig

  [*] Package  --->
      [*] CRASH and BUG Example  --->
          [*] Example: Module Common  --->

BiscuitOS/output/linux-5.0-x86_64/package/BiscuitOS-crash-module-common-default

实践例子是一个独立模块，模块基于 MISC 驱动框架进行构建。模块中提供了 write 接口，在 BiscuitOS_write() 函数中，存在一个空指针的引用。如果在用户空间向该驱动写入操作的时候，就会触发空指针的引用，这个时候就会触发内核 PANIC，最终获得内核转储文件。接着在 BiscuitOS 上实践该实例，并使用 CRASH 进行调试:

在 BiscuitOS 上运行实例之前，先将 PANIC 的 OOPS 选项设置为 1，以免 OOPS 被 killed，具体命令 “sysctl -w kernel.panic_on_oops=1”.

接着加载模块 “BiscuitOS-crash-module-common-default.ko”, 此时触发内核核心转储，此时通过不同的方法获得内核核心转储文件，并对其进行分析:

在使用 CRASH 分析内核转储文件时，使用 mod 命令查看模块是否加载符号表，第一次查看的时候发现 CRASH 没有加载模块的符号表。

接着使用 “mod -s” 命令进行加载，加载之前先将模块的目标文件拷贝到指定目录，然后进行加载，加载完毕之后再次使用 mod 命令查看模块的符号表，这个时候可以看到模块的符号表和 debuginfo 信息已经加载到 CRASH。

值得注意的时，如果某个模块在加载时出错，那么 CRASH 无法将该模块的符号表和 debuginfo 信息加载到 CRASH 内进行分析, 此时 CRASH 会认为这是一个非法模块，例如下图中不存在的模块:

mod -d <module> 移除模块的符号表和 debuginfo

在使用 CRASH 分析模块的时候，可以使用 “mod -s” 选项将模块的符号表和 debuginfo 动态加载到 CRASH 中进行分析。但有的时候需要更新模块的符号表或者移除模块的符号表，这个时候可以使用 “mod -d” 选项。该选项用于移除模块的符号表和 debuginfo，该选项的命令格式如下:

mod -d module

在 mod 命令的 “-d” 选项中，module 为模块的名字，值得注意的是 module 必须是一个模块名字，该命令可以通过 lsmod 进行查看，否则模块名字不对将被认为非法模块。

接下来通过一个实践例子研究该选项的使用。在 BiscuitOS 中提供了一个实践案例用于介绍该命令的使用，其部署流程如下 (以 linux 5.0 X86_64 为例):

cd BiscuitOS
make linux-5.0-x86_64_defconfig
make menuconfig

  [*] Package  --->
      [*] CRASH and BUG Example  --->
          [*] Example: Module Common  --->

BiscuitOS/output/linux-5.0-x86_64/package/BiscuitOS-crash-module-common-default

实践例子是一个独立模块，模块基于 MISC 驱动框架进行构建。模块中提供了 write 接口，在 BiscuitOS_write() 函数中，存在一个空指针的引用。

如果在用户空间向该驱动写入操作的时候，就会触发空指针的引用，这个时候就会触发内核 PANIC，最终获得内核转储文件。接着在 BiscuitOS 上实践该实例，并使用 CRASH 进行调试:

在 BiscuitOS 上运行实例之前，先将 PANIC 的 OOPS 选项设置为 1，以免 OOPS 被 killed，具体命令 “sysctl -w kernel.panic_on_oops=1”. 接着加载模块 “BiscuitOS-crash-module-common-default.ko”, 此时触发内核核心转储，此时通过不同的方法获得内核核心转储文件，并对其进行分析:

在使用 CRASH 分析内核转储文件时，使用 “mod -d” 命令移除模块的符号表和 debuginfo，在某些特定需求下这样的命令很有用。

mod 打印内核转储时系统中模块的信息

CRASH 提供 mod 命令可以查看内核转储时安装到系统的模块信息，各项的含义如下:

• MODULE 模块在的地址
• NAME 模块的名字
• SIZE 模块的长度
• OBJECT FILE 模块的目标文件

mod -S [directory] 从指定路径加载模块的目标文件

CRASH mod 在分析内核模块的时候，模块默认没有将对应的目标文件加入到 CRASH 内，mod 提供了 “-S” 选项可以将所有模块的目标文件都加载到 CRASH 内，如果 “-S” 后面没有跟路径信息，那么 CRASH 默认从主机的 “/lib/modules/$(uname -r)” 目录下进行查找并加载。接下来以一个实践例子进行讲解，在 BiscuitOS 中提供了一个实践案例用于介绍该命令的使用，其部署流程如下 (以 linux 5.0 X86_64 为例):

cd BiscuitOS
make linux-5.0-x86_64_defconfig
make menuconfig

  [*] Package  --->
      [*] CRASH and BUG Example  --->
          [*] Example: Module Common  --->

BiscuitOS/output/linux-5.0-x86_64/package/BiscuitOS-crash-module-common-default

实践例子是一个独立模块，模块基于 MISC 驱动框架进行构建。模块中提供了 write 接口，在 BiscuitOS_write() 函数中，存在一个空指针的引用。如果在用户空间向该驱动写入操作的时候，就会触发空指针的引用，这个时候就会触发内核 PANIC，最终获得内核转储文件。接着在 BiscuitOS 上实践该实例，并使用 CRASH 进行调试:

在 BiscuitOS 上运行实例之前，先将 PANIC 的 OOPS 选项设置为 1，以免 OOPS 被 killed，具体命令 “sysctl -w kernel.panic_on_oops=1”. 接着加载模块 “BiscuitOS-crash-module-common-default.ko”, 此时触发内核核心转储，此时通过不同的方法获得内核核心转储文件，并对其进行分析:

如果 “-S” 之后指明了路径，那么 CRASH 从指定的路径进行查找并加载目标文件。另外 CRASH 在启动命令上支持 “–mod " 的方式指明目标文件的路径，两者作用效果一致.

sudo crash kdump vminux --mod <mod_path>

mod -D 移除所有模块的目标文件

在使用 CRASH 分析模块的时候，可以使用 “mod -s/S” 选项将模块的符号表和 debuginfo 动态加载到 CRASH 中进行分析。但有的时候需要更新模块的符号表或者移除模块的符号表，这个时候可以使用 “mod -d” 选项一个一个移除比较慢，CRASH 提供了 “mod -D” 命令可以一次性将所有模块的目标文件移除。该选项的命令格式如下:

mod -D

在 mod 命令的 “-D” 选项中，无需跟任何参数就可以将所有模块的目标文件移除。接下来通过一个实践例子研究该选项的使用。在 BiscuitOS 中提供了一个实践案例用于介绍该命令的使用，其部署流程如下 (以 linux 5.0 X86_64 为例):

cd BiscuitOS
make linux-5.0-x86_64_defconfig
make menuconfig

  [*] Package  --->
      [*] CRASH and BUG Example  --->
          [*] Example: Module Common  --->

BiscuitOS/output/linux-5.0-x86_64/package/BiscuitOS-crash-module-common-default

实践例子是一个独立模块，模块基于 MISC 驱动框架进行构建。模块中提供了 write 接口，在 BiscuitOS_write() 函数中，存在一个空指针的引用。如果在用户空间向该驱动写入操作的时候，就会触发空指针的引用，这个时候就会触发内核 PANIC，最终获得内核转储文件。接着在 BiscuitOS 上实践该实例，并使用 CRASH 进行调试:

在 BiscuitOS 上运行实例之前，先将 PANIC 的 OOPS 选项设置为 1，以免 OOPS 被 killed，具体命令 “sysctl -w kernel.panic_on_oops=1”. 接着加载模块 “BiscuitOS-crash-module-common-default.ko”, 此时触发内核核心转储，此时通过不同的方法获得内核核心转储文件，并对其进行分析:

在使用 CRASH 分析内核转储文件时，使用 “mod -D” 命令移除所有模块的符号表和 debuginfo，在某些特定需求下这样的命令很有用。

lsmod 查看内核崩溃是加载的模块

CRASH 提供 lsmod 命令可以查看内核转储时安装到系统的模块信息，各项的含义如下:

• MODULE 模块在的地址
• NAME 模块的名字
• SIZE 模块的长度
• OBJECT FILE 模块的目标文件

Crash 链表操作

在内核中存在很多链表，例如常见的单链表和双链表。当内核发生崩溃时，使用 CRASH 分析内核转储文件时，对于链表上的内容分析可以采用 struct 或者 p 指令进行分析，但这两个指令无法满足对于整个链表内容的快速便捷分析，于是 CRASH 提供了 list 指令用来分析链表的内容。具体命令格式如下:

list 命令用于打印以链表链接起来的数据结构的内容。list 命令主要处理两种链表关系，第一种链表是单链表关系:

单链表关系一般内嵌在数据结构中，用于指向一下个同类型的数据结构。在这种情况下，list 命令的 start 参数指向了包含链表的数据结构的起始地址。该单链表的 next 指针可能指向一个空指针，也可能作为一个链表的表头，也可能指向自己，或者可能指向下一个同样数据结构的结构体。

内核中更多存在的是双链表关系，该关系可以指向前一个数据结构和后一个数据结构，在内核中通常使用 struct list_head 数据结构进行描述。该数据结构可能作为成员嵌入在某个数据结构中，或者作为指针嵌入在数据结构中。无论以何种方式嵌入，双链表都会将包含该链表的数据结构前后链接成一个双链表。CRASH list 命令提供了多个选项用于打印链表的内容:

list structure.member <start> 通过单链表成员起始地址打印单链表所有成员的地址

CRASH list 命令可以用于打印单链表成员的地址，并使用 “structure.member” 的方式将单链表上的数据结构地址打印出来。接下来通过一个实践例子研究该选项的使用。在 BiscuitOS 中提供了一个实践案例用于介绍该命令的使用，其部署流程如下 (以 linux 5.0 X86_64 为例):

cd BiscuitOS
make linux-5.0-x86_64_defconfig
make menuconfig

  [*] Package  --->
      [*] CRASH and BUG Example  --->
          [*] Example: list Common  --->

BiscuitOS/output/linux-5.0-x86_64/package/BiscuitOS-crash-list-common-default

实践例子是一个独立模块，模块基于 MISC 驱动框架进行构建。在模块中构建名为 BiscuitOS_node 的结构体，该结构体的 name 成员用于包含名字相关的字符串; 成员 list 为内嵌在结构体中双链表数据结构，该成员将 BiscuitOS_node 链接成双链表的关系; 成员 next 则为指向相同数据类型的指针，该指针构成一个 BiscuitOS_node 的单链表。模块定义了一个双链表的表头 BiscuitOS_list, 以及定义了 6 个 struct BiscuitOS_node 变量，每个变量都有独立的名字。模块中提供了 write 接口，在 BiscuitOS_write() 函数中，通过调用 list_add_tail() 函数将 6 个成员链接到 BiscuitOS_list 双链表上。函数紧接着将 node0 的 next 成员指向 node1, 以此类推，构建了 node0 到 node6 的单链表。最后 BiscuitOS_write() 函数中存在一个空指针的引用。如果在用户空间向该驱动写入操作的时候，就会触发空指针的引用，这个时候就会触发内核 PANIC，最终获得内核转储文件。接着在 BiscuitOS 上实践该实例，并使用 CRASH 进行调试:

在 BiscuitOS 上运行实例之前，先将 PANIC 的 OOPS 选项设置为 1，以免 OOPS 被 killed，具体命令 “sysctl -w kernel.panic_on_oops=1”. 接着加载模块 “BiscuitOS-crash-list-common-default.ko”, 此时触发内核核心>转储，此时通过不同的方法获得内核核心转储文件，并对其进行分析:

在实践例子中，node0 与其他 node 通过 next 构成了一个单链表，如果我想获得链表上所有 struct BiscuitOS_node 的地址，那么可以首先使用 struct 命令查看其数据结构布局，其中 next 成员作为一个 struct BiscuitOS_node 的指针，此时通过 p 命令获得 node0 的地址，接下来使用 “list BiscuitOS_node.next” 与 node0 的起始地址，就可以获得在这个链表上其他 struct BiscuitOS_node 的地址。最后借助 “-s” 命令打印 BiscuitOS_node 的 name 成员.

list [-o] offset <start> 通过单链表成员起始地址打印单链表所有成员的地址

CRASH list 命令可以用于打印单链表成员的地址，并使用 “[-o] offset” 的方式将单链表上的数据结构地址打印出来, 其中 offset 是嵌入在结构体中单链表成员的偏移。接下来通过一个实践例子研究该选项的使用。在 BiscuitOS 中提供了一个实践案例用于介绍该命令的使用，其部署流程如下 (以 linux 5.0 X86_64 为例):

cd BiscuitOS
make linux-5.0-x86_64_defconfig
make menuconfig

  [*] Package  --->
      [*] CRASH and BUG Example  --->
          [*] Example: list Common  --->

BiscuitOS/output/linux-5.0-x86_64/package/BiscuitOS-crash-list-common-default

实践例子是一个独立模块，模块基于 MISC 驱动框架进行构建。在模块中构建名为 BiscuitOS_node 的结构体，该结构体的 name 成员用于包含名字相关的字符串; 成员 list 为内嵌在结构体中双链表数据结构，该成员将 BiscuitOS_node 链接成双链表的关系; 成员 next 则为指向相同数据类型的指针，该指针构成一个 BiscuitOS_node 的单链表。模块定义了一个双链表的表头 BiscuitOS_list, 以及定义了 6 个 struct BiscuitOS_node 变量，每个变量都有独立的名字。模块中提供了 write 接口，在 BiscuitOS_write() 函数中，通过调用 list_add_tail() 函数将 6 个成员链接到 BiscuitOS_list 双链表上。函数紧接着将 node0 的 next 成员指向 node1, 以此类推，构建了 node0 到 node6 的单链表。最后 BiscuitOS_write() 函数中存在一个空指针的引用。如果在用户空间向该驱动写入操作的时候，就会触发空指针的引用，这个时候就会触发内核 PANIC，最终获得内核转储文件。接着在 BiscuitOS 上实践该实例，并使用 CRASH 进行调试:

在 BiscuitOS 上运行实例之前，先将 PANIC 的 OOPS 选项设置为 1，以免 OOPS 被 killed，具体命令 “sysctl -w kernel.panic_on_oops=1”. 接着加载模块 “BiscuitOS-crash-list-common-default.ko”, 此时触发内核核心转储，此时通过不同的方法获得内核核心转储文件，并对其进行分析:

在实践例子中，node0 与其他 node 通过 next 构成了一个单链表，如果我想获得链表上所有 struct BiscuitOS_node 的地址，那么可以首先使用 struct 命令查看 next 在 BiscuitOS_node 中的偏移，此时 next 的偏移为 24，此时通过 p 命令获得 node0 的地址，接下来使用 “-o 24” 与 node0 的起始地址，就可以获得在这个链表上其他 struct BiscuitOS_node 的地址。最后借助 “-s” 选项将单表成员的 name 成员打印出来.

list -H <start> 通过双链表表头起始地址打印双链表成员的地址

CRASH list 命令可以用于打印双链表成员的地址，内核通常使用在结构体嵌入 struct list_head 结构体构建双链表。CRASH list 提供了 “-H” 选项可以依据双链表的表头打印双链表上所有成员的地址。这里可以使用 “structure.member” 的方式指明双链表成员，也可以使用 “[-o] offset” 的方式指明双链表成员。接下来通过一个实践例子研究该选项的使用。在 BiscuitOS 中提供了一个实践案例用于介绍该命令的使用，其部署流程如下 (以 linux 5.0 X86_64 为例):

cd BiscuitOS
make linux-5.0-x86_64_defconfig
make menuconfig

  [*] Package  --->
      [*] CRASH and BUG Example  --->
          [*] Example: list Common  --->

BiscuitOS/output/linux-5.0-x86_64/package/BiscuitOS-crash-list-common-default

实践例子是一个独立模块，模块基于 MISC 驱动框架进行构建。在模块中构建名为 BiscuitOS_node 的结构体，该结构体的 name 成员用于包含名字相关的字符串; 成员 list 为内嵌在结构体中双链表数据结构，该成员将 BiscuitOS_node 链接成双链表的关系; 成员 next 则为指向相同数据类型的指针，该指针构成一个 BiscuitOS_node 的单链表。模块定义了一个双链表的表头 BiscuitOS_list, 以及定义了 6 个 struct BiscuitOS_node 变量，每个变量都有独立的名字。模块中提供了 write 接口，在 BiscuitOS_write() 函数中，通过调用 list_add_tail() 函数将 6 个成员链接到 BiscuitOS_list 双链表上。函数紧接着将 node0 的 next 成员指向 node1, 以此类推，构建了 node0 到 node6 的单链表。最后 BiscuitOS_write() 函数中存在一个空指针的引用。如果在用户空间向该驱动写入操作的时候，就会触发空指针的引用，这个时候就会触发内核 PANIC，最终获得内核转储文件。接着在 BiscuitOS 上实践该实例，并使用 CRASH 进行调试:

在 BiscuitOS 上运行实例之前，先将 PANIC 的 OOPS 选项设置为 1，以免 OOPS 被 killed，具体命令 “sysctl -w kernel.panic_on_oops=1”. 接着加载模块 “BiscuitOS-crash-list-common-default.ko”, 此时触发内核核心转储，此时通过不同的方法获得内核核心转储文件，并对其进行分析:

在实践例子中，node0 与其他 node 通过 list 成员都成了一个双链表，并以 BiscuitOS_list 为双链表的表头。那么首先通过 p 命令获得 BiscuitOS_list 的地址，接着通过 “structure.member” 的方式指明数据结构中的双链表成员，这里指定为 “BiscuitOS_node.list”. 那么接下来通过 “-H” 选项跟上双链表表头的地址，这样就可以遍历整个双链表。最后借助 “-s” 选项打印 BiscuitOS_node 成员的 name。另外也可以使用 offset 的方式:

list -h <start> 通过双链表成员起始地址打印双链表所有成员的地址

CRASH list 命令可以用于打印双链表成员的地址，内核通常使用在结构体嵌入 struct list_head 结构体构建双链表。CRASH list 提供了 “-h” 选项可以依据双链表的成员打印双链表上所有成员的地址。这里可以使用 “structure.member” 的方式指明双链表成员，也可以使用 “[-o] offset” 的方式指明双链表成员。接下来通过一个实践例子研究该选项的使用。在 BiscuitOS 中提供了一个实践案例用于介绍该命令的使用，其部署流程如下 (以 linux 5.0 X86_64 为例):

cd BiscuitOS
make linux-5.0-x86_64_defconfig
make menuconfig

  [*] Package  --->
      [*] CRASH and BUG Example  --->
          [*] Example: list Common  --->

BiscuitOS/output/linux-5.0-x86_64/package/BiscuitOS-crash-list-common-default

实践例子是一个独立模块，模块基于 MISC 驱动框架进行构建。在模块中构建名为 BiscuitOS_node 的结构体，该结构体的 name 成员用于包含名字相关的字符串; 成员 list 为内嵌在结构体中双链表数据结构，该成员将 BiscuitOS_node 链接成双链表的关系; 成员 next 则为指向相同数据类型的指针，该指针构成一个 BiscuitOS_node 的单链表。模块定义了一个双链表的表头 BiscuitOS_list, 以及定义了 6 个 struct BiscuitOS_node 变量，每个变量都有独立的名字。模块中提供了 write 接口，在 BiscuitOS_write() 函数中，通过调用 list_add_tail() 函数将 6 个成员链接到 BiscuitOS_list 双链表上。函数紧接着将 node0 的 next 成员指向 node1, 以此类推，构建了 node0 到 node6 的单链表。最后 BiscuitOS_write() 函数中存在一个空指针的引用。如果在用户空间向该驱动写入操作的时候，就会触发空指针的引用，这个时候就会触发内核 PANIC，最终获得内核转储文件。接着在 BiscuitOS 上实践该实例，并使用 CRASH 进行调试:

在 BiscuitOS 上运行实例之前，先将 PANIC 的 OOPS 选项设置为 1，以免 OOPS 被 killed，具体命令 “sysctl -w kernel.panic_on_oops=1”. 接着加载模块 “BiscuitOS-crash-list-common-default.ko”, 此时触发内核核心转储，此时通过不同的方法获得内核核心转储文件，并对其进行分析:

在实践例子中，node0 与其他 node 通过 list 成员都成了一个双链表，并以 BiscuitOS_list 为双链表的表头。那么首先通过 p 命令获得 node0 的地址，接着通过 “structure.member” 的方式指明数据结构中的双链表成员，这里指定为 “BiscuitOS_node.list”. 那么接下来通过 “-h” 选项跟上双链表成员的起始地址，这样就可以遍历整个双链表。最后借助 “-s” 选项打印 BiscuitOS_node 成员的 name。另外也可以使用 offset 的方式:

list -s/-S struct 打印链表成员的内容

CRASH list 命令可以用于打印链表成员的地址，但通常需要查看链表成员的内容，这个时候可以使用 “-s” 选项，其后跟上需要查看内容的成员描述，可以使用 “structure.member” 进行描述。”-S” 选项与 “-s” 类似，由于内容直接从内存中读取，比 “-s” 速度快一些。接下来通过一个实践例子研究该选项的使用。在 BiscuitOS 中提供了一个实践案例用于介绍该命令的使用，其部署流程如下 (以 linux 5.0 X86_64 为例):

cd BiscuitOS
make linux-5.0-x86_64_defconfig
make menuconfig

  [*] Package  --->
      [*] CRASH and BUG Example  --->
          [*] Example: list Common  --->

BiscuitOS/output/linux-5.0-x86_64/package/BiscuitOS-crash-list-common-default

实践例子是一个独立模块，模块基于 MISC 驱动框架进行构建。在模块中构建名为 BiscuitOS_node 的结构体，该结构体的 name 成员用于包含名字相关的字符串; 成员 list 为内嵌在结构体中双链表数据结构，该成员将 BiscuitOS_node 链接成双链表的关系; 成员 next 则为指向相同数据类型的指针，该指针构成一个 BiscuitOS_node 的单链表。模块定义了一个双链表的表头 BiscuitOS_list, 以及定义了 6 个 struct BiscuitOS_node 变量，每个变量都有独立的名字。模块中提供了 write 接口，在 BiscuitOS_write() 函数中，通过调用 list_add_tail() 函数将 6 个成员链接到 BiscuitOS_list 双链表上。函数紧接着将 node0 的 next 成员指向 node1, 以此类推，构建了 node0 到 node6 的单链表。最后 BiscuitOS_write() 函数中存在一个空指针的引用。如果在用户空间向该驱动写入操作的时候，就会触发空指针的引用，这个时候就会触发内核 PANIC，最终获得内核转储文件。接着在 BiscuitOS 上实践该实例，并使用 CRASH 进行调试:

在 BiscuitOS 上运行实例之前，先将 PANIC 的 OOPS 选项设置为 1，以免 OOPS 被 killed，具体命令 “sysctl -w kernel.panic_on_oops=1”. 接着加载模块 “BiscuitOS-crash-list-common-default.ko”, 此时触发内核核心转储，此时通过不同的方法获得内核核心转储文件，并对其进行分析:

在实践例子中，使用 “-h” 选项遍历了双链表，在遍历的时候使用 “-s” 选项可以查看链表成员的 name、next、以及 list 的值.

list -r 逆序输出链表

CRASH list 命令可以用于打印链表成员的地址，此时按链表的正序输出链表的成员地址。CRASH list 同时提供了 “-r” 选项实现逆序输出成员的地址，再结合其他选项可以输出符合要求的链表内容。接下来通过一个实践例子研究该选项的使用。在 BiscuitOS 中提供了一个实践案例用于介绍该命令的使用，其部署流程如下 (以 linux 5.0 X86_64 为例):

cd BiscuitOS
make linux-5.0-x86_64_defconfig
make menuconfig

  [*] Package  --->
      [*] CRASH and BUG Example  --->
          [*] Example: list Common  --->

BiscuitOS/output/linux-5.0-x86_64/package/BiscuitOS-crash-list-common-default

实践例子是一个独立模块，模块基于 MISC 驱动框架进行构建。在模块中构建名为 BiscuitOS_node 的结构体，该结构体的 name 成员用于包含名字相关的字符串; 成员 list 为内嵌在结构体中双链表数据结构，该成员将 BiscuitOS_node 链接成双链表的关系; 成员 next 则为指向相同数据类型的指针，该指针构成一个 BiscuitOS_node 的单链表。模块定义了一个双链表的表头 BiscuitOS_list, 以及定义了 6 个 struct BiscuitOS_node 变量，每个变量都有独立的名字。模块中提供了 write 接口，在 BiscuitOS_write() 函数中，通过调用 list_add_tail() 函数将 6 个成员链接到 BiscuitOS_list 双链表上。函数紧接着将 node0 的 next 成员指向 node1, 以此类推，构建了 node0 到 node6 的单链表。最后 BiscuitOS_write() 函数中存在一个空指针的引用。如果在用户空间向该驱动写入操作的时候，就会触发空指针的引用，这个时候就会触发内核 PANIC，最终获得内核转储文件。接着在 BiscuitOS 上实践该实例，并使用 CRASH 进行调试:

在 BiscuitOS 上运行实例之前，先将 PANIC 的 OOPS 选项设置为 1，以免 OOPS 被 killed，具体命令 “sysctl -w kernel.panic_on_oops=1”. 接着加载模块 “BiscuitOS-crash-list-common-default.ko”, 此时触发内核核心转储，此时通过不同的方法获得内核核心转储文件，并对其进行分析:

在实践例子中，使用 “-h” 选项遍历了双链表，在遍历的时候使用 “-s” 选项可以查看链表成员的 name、next、以及 list 的值. 此时使用 “-r” 选项逆序输出链表成员的内容.

Crash 系统内存统计信息

当使用 CRASH 分析内核转储文件时，系统的内存使用率对问题的定位提供了很多有用的信息，例如当前系统物理内存使用情况、物理页使用情况、SLAB 缓存数据情况等，CRASH 提供了 kmem 命令用于获得系统内存使用信息，如下 :

# SYNOPSIS
kmem [-f|-F|-c|-C|-i|-v|-V|-n|-z|-o|-h] [-p | -m member[,member]]
     [[-s|-S|-r] [slab] [-I slab[,slab]]] [-g [flags]] [[-P] address]]

kmem -i 打印系统物理内存使用情况

当使用 CRASH 解析内核转储文件时，使用 “kmem -i” 命令可以获得内核崩溃时系统物理内存的使用量，其各字段含义如下:

• PAGES 表示占有物理页的数量
• TOTAL 表示占用物理内存的数量
• PERCENTAGE 表示占用总物理内存的百分比
• TOTAL MEM 表示系统总共占用物理内存的情况
• FREE 表示系统中空闲物理内存的情况
• USED 表示系统中已经使用物理内存的情况
• SHARED 表示系统中共享物理内存使用情况
• BUFFERS 表示 Buffer 占用物理内存情况
• CACHED 表示 Page Cache 占用物理内存的情况
• TOTAL HUGE 表示系统中大页占用物理内存的数量
• HUGE FREE 表示系统中可用大页占用的物理内存数量
• TOTAL SWAP 表示 SWAP 空间的大小
• SWAP USED 表示 SWAP 空间已使用的数量
• SWAP FREE 表示 SWAP 空间空闲的数量

kmem -f 打印 ZONE 内 free_area 的信息

系统物理内存被划分成一个一个物理页，物理页通过 struct page 进行维护管理，每个物理页按循序进行编号，该号码称为物理页的页帧号，简称为 PFN. 系统在初始化过程中，将物理内存划分成不同的 Zone，Zone 也是一定物理页的集合，Zone 区域的物理页用于特定功能，例如 DMA/DMA32 Zone 的物理内存就用于特殊地址的外设使用，而 Normal Zone 的物理页则用于正常的内核活动，而 Highmem Zone 的物理页就给用户空间使用。Zone 通过 struct zone 进行管理和维护，struct zone 结构体中存在 free_area 成员，该成员是由 struct free_aera 组成长度为 11 的数组，位于该 Zone 的物理页基于其大小被 page->lru 链表链接到了不同 free_area[] 数组成员上，以此作为 Buddy 分配器物理页来源。

在 struct free_area 结构体中包含了一个 struct list 的数组，数组长度为 4，系统根据迁移类型将物理页划分成 MIGRATE_UNMOVABLE、MIGRATE_MOVABLE、MIGRATE_RECLAIMABLE、MIGRATE_PCPTYPES、MIGRATE_HIGHATOMIC、MIGRATE_CMA、MIGRATE_ISOLATE 种类，其中数组的长度为 MIGRATE_TYPES. 同样大小的物理页会因为迁移类型不同最终插入到不同的 free_list 上。基于上面的原理，CRASH kmem 命令提供了 “-f” 选项用于打印所有 Zone 上 free_area 信息，CRASH 可以根据这些信息获得更多有效的信息，其使用如下:

• ZONE 表明 Zone Idx 编号
• NAME 指明 Zone 的名字
• SIZE 该 Zone 物理页的总数
• FREE 空闲物理页的数量
• MEM_MAP 该 Zone 在 mem_map[] 数组中第一个 struct page 的地址
• START_PADDR 该 Zone 第一个物理页对应的物理地址
• START_MAPNR 该 Zone 第一个物理页在 mem_map[] 数组中的偏移
• AREA 表明该 free_arae 中物理页的 ORDER 大小
• SIZE 表明该 free_area 中物理页块的大小
• FREE_AREA_STRUCT 表明 free_area 中 free_list 的地址
• BLOCKS 表明该 free_area 中物理页块的数量
• PAGES 表明该 free_area 中物理页的数量

由于 “kmem -f” 是输出了所有 free_area 的 free_list 地址，该链表作为指定迁移类型的双链表表头，于是可以使用 “list” 命令将链表中的成员都打印出来。物理页 struct page 的 lru 成员通过物理页的迁移类型插入到指定的 free_list 双链表上，有了以上两个基础，使用 “list -H” 命令指向该双链表表头，然后借助 “list -s” 打印所需的内容，这里打印的物理页 struct page 的 flags 成员. 在上图的实例中，选择了 8k 的 ffff926a1ffdc608 作为研究对象.

kmem -v 打印 VMALLOC 分配器分配的内存信息

KMALLOC 内存分配器用于分配虚拟地址连续而物理地址不一定连续的内存，其从内核的虚拟区域中划分一段区域，起始与 VMALLOC_START, 终止于 VMALLOC_END. VMALLOC 分配器将每分配出去的区域使用 struct vmap_area 结构体进行描述，对于该区域对于的物理内存则通过 struct vm_struct 结构体进行描述，其定义如下:

CRASH 提供了 “kmem -v” 命令用于查看 VMALLOC 分配器分配的情况，通过该命令可以获得已经分配区域 struct vmap_area 的地址、struct vm_struct 的地址、区域的范围以及区域的大小。结合 CRASH 其它命令还可以获得更多有用的信息:

kmem -V 打印系统 vm_state 表内容

内核将物理内存根据用途划分为不同的 Zone，每个 Zone 通过 struct zone 结构体进行维护，该结构体中包含了 vm_state/vm_numa_state 等用于统计内存使用情况的成员，内核在统计内存使用情况时，其从各个 Zone 的 struct zone 成员中读取数据进行统计。其中 struct zone 的 vm_state 成员通过 enum zone_state_item 进行描述，其具体成员包括:

• NR_FREE_PAGES Zone 中空闲物理页的数量
• NR_ZONE_LRU_BASE Zone 中压缩和回收 LRU 基础物理页数量
• NR_ZONE_INACTIVE_ANON Zone 中不活跃匿名页的数量
• NR_ZONE_ACTIVE_ANON Zone 中活跃匿名页的数量
• NR_ZONE_INACTIVE_FILE Zone 中不活跃的文件映射页数量
• NR_ZONE_ACTIVE_FILE Zone 中活跃的文件映射页数量
• NR_ZONE_UNEVICTABLE
• NR_ZONE_WRITE_PENDING Zone 中脏页的数量
• NR_MLOCK mlock 的页数量
• NR_PAGETABLE Zone 中页表页的数量
• NR_KERNEL_STACK_KB
• NR_BOUNCE
• NR_ZSPAGES ZSMALLOC 分配器分配的物理页数量
• NR_FREE_CMA_PAGES Zone 上空闲的 CMA 物理页数量

CRASH 提供的 “kmem -V” 命令可以查看内核崩溃时所有 Zone 的 vm_state 统计数据. CRASH 打印的 VM_ZONE_STATE 数据项目正好以 enum zone_state_item 中的项目对应上, 因此可以通过这些数据分析内核崩溃时一些物理页的使用信息.

kmem -V 打印系统 vm_node_state 表内容

在多 NUMA NODE 或者单 NUMA NODE 的系统中，内核使用 struct pglist_data 结构体维护一个 NUMA NODE，在其中包含了 vm_state 成员，该成员统计了该 NUMA NODE 上物理页使用情况。该 vm_state 的成员通过 enum node_state_item 进行定义，其具体成员如下:

• NR_LRU_BASE NODE 上 LRU 物理页的最小值
• NR_INACTIVE_ANON NODE 上不活跃匿名页的数量
• NR_ACTIVE_ANON NODE 上活跃匿名页的数量
• NR_INACTIVE_FILE NODE 上不活跃文件映射页的数量
• NR_ACTIVE_FILE NODE 上活跃文件映射页的数量
• NR_UNEVICTABLE
• NR_SLAB_RECLAIMABLE NODE 上 SLAB 回收物理页的数量
• NR_SLAB_UNRECLAIMABLE NODE 上 SLAB 不可回收物理页的数量
• NR_ISOLATED_ANON NODE 上 LRU 链表里孤立匿名页的数量
• NR_ISOLATED_FILE NODE 上 LRU 链表里孤立 Page Cache 页数量
• WORKINGSET_NODES
• WORKINGSET_REFAULT
• WORKINGSET_ACTIVATE
• WORKINGSET_RESTORE
• WORKINGSET_NODERECLAIM
• NR_ANON_MAPPED NODE 上匿名映射物理页的数量
• NR_FILE_MAPPED NODE 上文件映射物理页的数量
• NR_FILE_PAGES NODE 上 Page Cache 页的数量
• NR_FILE_DIRTY NODE 上文件脏页的数量
• NR_WRITEBACK NODE 上回写物理页的数量
• NR_WRITEBACK_TEMP
• NR_SHMEM NODE 上共享页的数量
• NR_SHMEM_THPS NODE 上共享透明大页的数量
• NR_SHMEM_PMDMAPPED NODE 上共享 PMD 映射的大页数量
• NR_ANON_THPS NODE 上匿名透明大页的数量
• NR_UNSTABLE_NFS
• NR_VMSCAN_WRITE
• NR_VMSCAN_IMMEDIATE
• NR_DIRTIED
• NR_WRITTEN
• NR_KERNEL_MISC_RECLAIMABLE

CRASH 提供的 “kmem -V” 命令可以查看内核崩溃时所有 NODE 的 vm_state 统计数据. CRASH 打印的 VM_NODE_STATE 数据项目正好以 enum node_state_item 中的项目对应上, 因此可以通过这些数据分析内核崩溃时一些物理页的使用信息.

kmem -V 打印系统 vm_numa_state 表内容

内核将物理内存根据用途划分为不同的 Zone，每个 Zone 通过 struct zone 结构体进行维护，该结构体中包含了 vm_state/vm_numa_state 等用于统计内存使用情况的成员，内核在统计内存使用情况时，其从各个 Zone 的 struct zone 成员中读取数据进行统计。Zone 可能位于一个或多个 NUNA NODE 之上，通常情况下本地 CPU 应从本地 NUMA NODE 上分配物理内存，只有本地物理内存不够用时才从其他 NUMA NODE 上分配物理内存。另外 struct zone 的 vm_numa_state 成员通过 enum numa_state_item 进行描述，其具体成员包括:

• NUMA_HIT 在该 NUMA NODE 上分配物理页的数量
• NUMA_MISS 在其他 NUMA NODE 上分配物理页的数量
• NUMA_FOREIGN
• NUMA_INTERLEAVE_HIT
• NUMA_LOCAL
• NUMA_OTHER

CRASH 提供的 “kmem -V” 命令可以查看内核崩溃时所有 ZONE 的 vm_numa_state 统计数据. CRASH 打印的 VM_NUMA_STATE 数据项目正好以 enum numa_state_item 中的项目对应上, 因此可以通过这些数据分析内核崩溃时一些物理页的使用信息.

kmem -V 打印系统 vm_event_state 表内容

内核使用 vm_event_states 统计所有内存事件，其属于 struct vm_event_state 结构体，其包含了一个长度为 NR_VM_EVENT_ITEMS 的 unsigned long 数组。vm_event_states 维护的事件类型通过 enum vm_event_item 定义:

CRASH 提供的 “kmem -V” 命令可以查看内核崩溃时所有内存事件的统计数据，其数据来源正好是 vm_event_states 变量。因此可以通过这些数据分析内核崩溃时的内存情况:

kmem -n 打印内存模型下的物理内存信息

内核支持平坦内存模式和 SPARSE 内存模型，平坦内存模型会将物理内存当做一个整体，并将整体按顺序划分成一块块的物理页，每个物理页都有各自的物理页帧号; SPARSE 内存模型则将物理内存划分成一块一块的 memory section，在每个 memory section 内部再按顺序划分成一块块物理页，每个物理页也有属于自己的物理页帧号。两种模型都有各自的特点，从物理页的角度来看，来自似乎是一致的。但 SPARSE 内存模型多用于 NUMA 架构下，内核使用 struct pglist_data 结构体来描述一个 NUMA NODE，其定义如下:

在 struct pglist_data 结构体中包含了 node_zones[] 数组，该数组维护了该 NODE 下 Zone 的信息，内核使用 struct zone 结构体来描述一个 Zone，每个 NODE 能包含的最大 Zone 数量通过 MAX_NR_ZONES 进行指定。在每个 NODE 下包含了多个 ZONE，这些 Zone 可能是 ZONE_DMA/ZONE_DMA32/ZONE_Normal/ZONE_Movable/ZONE_Highmem 等。物理页通过 struct page 结构体进行描述，内核将所有的 struct page 放置在 mem_map[] 数组中。由于在 SPARSE 内存模型中，内核将多个物理页组成一个 memory section，该 memory section 就是物理页的集合，其通过 struct mem_section 结构体进行维护。CRASH 提供了 “kmem -n” 命令就是用于打印内核模型下物理内存信息, 其各字段含义如下:

• NODE 字段描述了 NUMA NODE ID
• SIZE 字段描述了 Memory Section 的大小，以 KB 为单位
• PGLIST_DATA 字段描述 NUMA NODE 对应 struct pglist_data 的地址
• BOOTMEM_DATA 字段描述了 BOOT NUMA NODE 对应 struct bootmem_data 的地址
• NODE_ZONES 描述了该 NUMA NODE 下对应 ZONE struct zone 的地址
• MEM_MAP 字段描述了系统 mem_map[] 的地址
• START_PADDR 描述了 mem_map[] 第一个成员对应的物理地址
• START_MAPNR 描述了 mem_map[] 第一个成员对应的物理页帧号
• ZONE NAME 字段描述了 ZONE 的名字
• SIZE 字段描述了该 ZONE 中包含物理页的数量
• MEM_MAP 字段描述该 ZONE 的起始物理页在 mem_map[] 中的地址
• START_PADDR 字段描述 ZONE 的起始物理页对应的物理地址
• START_MAPNR 字段描述 ZONE 的起始物理页帧号
• NR 字段描述了 memory section 的 SECTION ID
• SECTION 字段描述该 memory section 对应的 struct mem_section 地址
• CODED_MEM_MAP 字段描述该 Section 对应的 mem_map
• MEM_MAP 字段描述该 Section 起始物理页在 mem_map[] 中的地址
• PFN 字段描述了该 Section 的起始物理页帧号
• STATE 字段描述了 Section 的状态 (P: SECTION_MARKED_PRESENT, M: SECTION_HAS_MEM_MAP, O: SECTION_IS_ONLINE, E: SECTION_IS_EARLY)
• MEM_BLOCK 字段描述 struct memory_block 的地址
• NAME 字段描述 MEM_BLOCK 的名字
• PHYSICAL RANGE 字段描述 MEM_BLOCK 的物理内存范围
• STATE 字段描述 MEM_BLOCK 的状态
• START_SECTION_NO 字段描述 MEM_BLOCK 所在的 SECTION ID.

kmem -z 打印所有 Zone 的统计信息

内核将内存划分成不同的 ZONE 进行维护，不同的 ZONE 用于不同的目的。ZONE_DMA 主要给一些老式的设备使用的内存，ZONE_DMA32 主要给内核和一些新的外设使用，ZONE_Normal 则给基础的内核活动使用，ZONE_Highmem 则给用户使用的物理内存，ZONE_Movable 则是可以移动的物理内存。ZONE 通过 struct zone 结构体进行描述，其包含了该 Zone 的内存使用统计信息。CRASH 提供了 “kmem -z” 命令可以用于查看所有 ZONE 的上的统计信息，其个字段含义如下:

• NODE 字段指明 ZONE 所在的 NUMA NODE
• ZONE 字段指明 ZONE ID
• ADDR 字段指明 ZONE 对应 struct zone 的地址
• NAME 字段指明了 ZONE 的名字
• SIZE 字段指明了 ZONE 中包含物理页的数量
• PRESENT 字段指明了实际存在的物理页数量
• MIN/LOW/HIGH 字段指明了该 ZONE 的物理内存水位线
• VM_STAT 字段指明了 Zone 的 vm_state 统计信息
• NR_FREE_PAGES Zone 中空闲物理页的数量
• NR_ZONE_LRU_BASE Zone 中压缩和回收 LRU 基础物理页数量
• NR_ZONE_INACTIVE_ANON Zone 中不活跃匿名页的数量
• NR_ZONE_ACTIVE_ANON Zone 中活跃匿名页的数量
• NR_ZONE_INACTIVE_FILE Zone 中不活跃的文件映射页数量
• NR_ZONE_ACTIVE_FILE Zone 中活跃的文件映射页数量
• NR_ZONE_UNEVICTABLE
• NR_ZONE_WRITE_PENDING Zone 中脏页的数量
• NR_MLOCK mlock 的页数量
• NR_PAGETABLE Zone 中页表页的数量
• NR_KERNEL_STACK_KB
• NR_BOUNCE
• NR_ZSPAGES ZSMALLOC 分配器分配的物理页数量
• NR_FREE_CMA_PAGES Zone 上空闲的 CMA 物理页数量

kmem -h 打印大页内存信息

CRASH 提供了 “kmem -h” 命令可以查看大页的使用情况，各字段的含义如下:

• SIZE 大页的体积

原文链接：https://biscuitos.github.io/blog/CRASH/#D1 版权归原作者所有，如有侵权，请联系作者删除