RK3588 平台关联与使用场景详解

源码路径：rk3588/kernel-6.1/ipc/（通用实现）
文档目录：linuxDoc/ipc/

目录

• 一、平台结论
• 二、内核配置建议
• 三、与 SeagullYpcEncode / 嵌入式
• 四、容器与调试

一、平台结论

RK3588 行为与上游 Linux 6.1 一致。

二、内核配置建议

POSIX_MQUEUE 依赖 NET：裁网络时要连带注意。

三、与 SeagullYpcEncode / 嵌入式

VPU/RGA 零拷贝 不走 ipc/shm.c；详见驱动与 linuxDoc/mm。

四、容器与调试

1
2
3
4
5
6
7

# 主机
ipcs -a
ls /proc/sysvipc/
readlink /proc/self/ns/ipc

# 容器内独立 IPC NS 时，主机 ipcs 看不到容器内对象
docker run --ipc private ...

关联文档

• 总览
• 04 共享内存
• linuxDoc/init（ipc_init 启动顺序）

ipc/ 进程间通信机制与原理详解

源码路径：rk3588/kernel-6.1/ipc/
内核版本：Linux 6.1（RK3588 / ARM64）
文档目录：linuxDoc/ipc/

内核 IPC 子系统实现两类机制：System V IPC（信号量、消息队列、共享内存）与 POSIX 消息队列（mqueue 文件系统）。现代应用更多使用 管道、Unix socket、memfd、io_uring，但 SysV/POSIX mq 仍广泛用于遗留服务、数据库与 容器命名空间隔离。

目录

• 一、子系统职责
• 二、架构关系
• 三、统一 ID 与权限模型
• 四、与 RK3588 关系
• 功能组专题

一、子系统职责

二、架构关系

三、统一 ID 与权限模型

3.1 IPC ID 编码（util.h）

• index（低 15 位，或扩展模式 24 位）+ sequence（防 id 重用 UAF）
• ipc_addid / ipc_rmid 管理 idr；ipc_findkey 走 rhashtable

3.2 创建路径 ipcget

1. IPC_PRIVATE：直接 getnew
2. IPC_CREAT | key：ipcget_public 查表或创建
3. 权限：ipcperms + LSM security_*_associate

3.3 锁（util.c 头注释）

• RCU 查找 kern_ipc_perm
• 每对象 kern_ipc_perm.lock 做修改类操作
• ids->rwsem：创建/删除/遍历 id 集、/proc/sysvipc

四、与 RK3588 关系

• 无平台补丁；ARM64 使用独立 syscall（semop 等），一般不依赖旧 ipc()
• 嵌入式若裁掉 SYSVIPC 可缩小内核，但 glibc/部分中间件 可能仍需要
• 容器/Android 命名空间 依赖 IPC_NS 时本目录为必需

详见 07。

功能组专题

ipc 文档索引

Linux 6.1（RK3588）内核 进程间通信（IPC） 子系统源码分析与原理说明。

总览文档

功能组专题（原理 + 实现）

源码路径

1
2
3

rk3588/kernel-6.1/ipc/
include/linux/ipc_namespace.h
include/linux/msg.h、sem.h、shm.h

阅读顺序建议

速查

关联文档

• 内存管理（shm 页、VMA）：linuxDoc/mm
• 命名空间总览：kernel/nsproxy.c（不在 ipc/）
• 启动初始化：device_initcall(ipc_init) → linuxDoc/init

ipc/ 源码目录与模块索引

源码路径：rk3588/kernel-6.1/ipc/（13 个文件）
内核版本：Linux 6.1（RK3588 / ARM64）
文档目录：linuxDoc/ipc/

一、文件清单

平台：无 Rockchip 专用代码。

二、Makefile

1
2
3
4
5
6

obj-$(CONFIG_SYSVIPC)         += util.o msgutil.o msg.o sem.o shm.o syscall.o
obj-$(CONFIG_SYSVIPC_SYSCTL)  += ipc_sysctl.o
obj-$(CONFIG_SYSVIPC_COMPAT)  += compat.o
obj-$(CONFIG_POSIX_MQUEUE)    += mqueue.o msgutil.o
obj-$(CONFIG_IPC_NS)          += namespace.o
obj-$(CONFIG_POSIX_MQUEUE_SYSCTL) += mq_sysctl.o

msgutil.o 可被 SysV 与 mqueue 共享编译。

三、Kconfig（init/Kconfig）

四、ipc_namespace 与三类 ID

include/linux/ipc_namespace.h：

1
2
3
4
5
6

struct ipc_namespace {
    struct ipc_ids ids[3];  // SEM, MSG, SHM
    // sem_ctls[], msg_ctl*, shm_ctl*
    struct vfsmount *mq_mnt;  // POSIX mqueue
    ...
};

每类使用 struct ipc_ids：idr（按 id 查找）+ rhashtable（按 key 查找）+ rwsem。

五、初始化顺序

六、专题对照

kernel/bpf 内核 BPF 机制与原理详解

源码路径：rk3588/kernel-6.1/kernel/bpf/
内核版本：Linux 6.1（RK3588 平台）
平台：RK3588（4×Cortex-A76 + 4×Cortex-A55 big.LITTLE）

该目录实现 Linux 内核 eBPF（extended BPF） 子系统的核心代码。eBPF 允许用户空间加载经过严格验证的字节码程序，在内核中安全、高效地执行，用于网络过滤、追踪、安全策略、 cgroup 管控等场景。所有操作通过 bpf() 系统调用及文件描述符（prog/map/link fd）完成。

目录

• 一、源码目录结构
• 二、整体架构
• 三、核心数据结构
• 四、bpf() 系统调用
• 五、程序加载与验证器
• 六、程序执行引擎
• 七、Map 映射类型
• 八、Helper 辅助函数
• 九、BTF 类型系统
• 十、程序挂载与 Trampoline
• 十一、Cgroup BPF 与 LSM
• 十二、BPF Iterator 与 Link
• 十三、网络相关 Map
• 十四、完整加载执行时序
• 十五、RK3588 平台调试建议
• 十六、总结

一、源码目录结构

1.1 编译依赖关系（Kconfig）

1
2
3
4
5
6
7

BPF (基础 classic BPF 解释器)
    └── BPF_SYSCALL (menuconfig "BPF subsystem")
            ├── BPF_JIT              ← JIT 编译器
            ├── BPF_JIT_ALWAYS_ON    ← 永久启用 JIT，移除解释器
            ├── BPF_UNPRIV_DEFAULT_OFF ← 默认禁止非特权 BPF
            ├── BPF_LSM              ← LSM 安全钩子挂载
            └── BPF_PRELOAD          ← 启动时预加载 BPF 程序

关键配置项：

1.2 编译单元（Makefile）

1.3 主要源文件分类

核心基础设施

Map 实现

网络相关

挂载与迭代

预加载

二、整体架构

2.1 分层模型

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

┌─────────────────────────────────────────────────────────────┐
│                    用户空间                                  │
│   libbpf / bpftool / clang -target bpf                       │
└──────────────────────────┬──────────────────────────────────┘
                           │ bpf() syscall + fd (prog/map/link)
┌──────────────────────────▼──────────────────────────────────┐
│                   syscall.c                                  │
│  __sys_bpf() │ prog_load │ map_create │ link_create          │
└──────┬──────────┬──────────┬──────────┬─────────────────────┘
       │          │          │          │
┌──────▼──┐ ┌─────▼────┐ ┌──▼──────┐ ┌─▼──────────────┐
│Verifier │ │ Map Ops  │ │  BTF    │ │ Trampoline/    │
│verifier │ │ array/   │ │  btf.c  │ │ Attach/Link    │
│  .c     │ │ hashtab  │ │         │ │ trampoline.c   │
└──────┬──┘ └─────┬────┘ └──┬──────┘ └─┬──────────────┘
       │          │          │          │
       └──────────┴──────────┴──────────┘
                           │
              ┌────────────▼────────────┐
              │   core.c + arch JIT     │
              │   解释器 / JIT 机器码    │
              │   bpf_prog_run()        │
              └────────────┬────────────┘
                           │
              ┌────────────▼────────────┐
              │   内核 Hook 点           │
              │ XDP/cgroup/trace/LSM/   │
              │ kprobe/fentry/...       │
              └─────────────────────────┘

2.2 核心设计原则

• 安全优先：所有用户加载的程序必须经过 verifier 静态验证，保证有界执行、类型安全、无非法内存访问
• JIT 加速：默认通过架构相关 JIT（ARM64: arch/arm64/net/bpf_jit_comp.c）编译为本地代码
• Map 共享状态：prog 通过 fd 引用 map，实现内核与用户空间、prog 与 prog 之间的数据共享
• Link 抽象：BPF link 统一管理 prog 与挂载点的生命周期
• BTF 类型安全：携带 BTF 的程序支持 CO-RE、typed context access、fentry/fexit

三、核心数据结构

3.1 struct bpf_prog — BPF 程序

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

// include/linux/filter.h
struct bpf_prog {
    u16                     pages;          // 程序占用页数
    u16                     jited:1,      // 是否已 JIT
                            gpl_compatible:1,
                            jit_requested:1,
                            blinding_requested:1;
    enum bpf_prog_type      type;         // 程序类型
    enum bpf_attach_type    expected_attach_type;
    u32                     len;            // 指令数
    struct bpf_insn        *insnsi;        // eBPF 指令数组
    struct bpf_prog_aux    *aux;           // 扩展信息
    unsigned int           (*bpf_func)(const void *ctx,
                                       const struct bpf_insn *insn);
    // JIT 后 bpf_func 指向编译后的机器码
};

bpf_prog_aux 包含 BTF、used_maps、attach 信息、stats、line info 等。

3.2 struct bpf_map — BPF 映射

1
2
3
4
5
6
7
8
9
10

// include/linux/bpf.h
struct bpf_map {
    const struct bpf_map_ops *ops;   // 虚函数表
    enum bpf_map_type       map_type;
    u32                     key_size;
    u32                     value_size;
    u32                     max_entries;
    atomic64_t              writecnt; // 并发写计数
    // ...
};

3.3 struct bpf_map_ops — Map 虚函数表

1
2
3
4
5
6
7
8
9

struct bpf_map_ops {
    int (*map_alloc_check)(union bpf_attr *attr);
    struct bpf_map *(*map_alloc)(union bpf_attr *attr);
    void (*map_free)(struct bpf_map *map);
    void *(*map_lookup_elem)(struct bpf_map *map, void *key);
    int (*map_update_elem)(struct bpf_map *map, void *key, void *value, u64 flags);
    int (*map_delete_elem)(struct bpf_map *map, void *key);
    // ...
};

各 map 类型在 linux/bpf_types.h 中通过 BPF_MAP_TYPE 宏注册到 bpf_map_types[]。

3.4 struct bpf_insn — eBPF 指令

1
2
3
4
5
6
7
8

// include/uapi/linux/linux/bpf.h
struct bpf_insn {
    __u8    code;       // 操作码
    __u8    dst_reg:4;  // 目标寄存器
    __u8    src_reg:4;  // 源寄存器
    __s16   off;        // 跳转偏移
    __s32   imm;        // 立即数
};

寄存器约定：

• R0 — 返回值
• R1-R5 — 参数传递（R1 = context 指针）
• R6-R9 — callee saved
• R10 — 帧指针（只读）

3.5 struct bpf_link — 挂载链接

1
2
3
4
5
6
7
8

struct bpf_link {
    atomic64_t              refcnt;
    u32                     id;
    enum bpf_link_type      type;
    struct bpf_link_ops    *ops;     // release/dealloc/update_map
    struct bpf_prog        *prog;
    // ...
};

Link 替代旧的 BPF_PROG_ATTACH 方式，提供更清晰的生命周期管理。

四、bpf() 系统调用

4.1 入口

1
2
3
4
5

// syscall.c
SYSCALL_DEFINE3(bpf, int, cmd, union bpf_attr __user *, uattr, unsigned int, size)
{
    return __sys_bpf(cmd, USER_BPFPTR(uattr), size);
}

4.2 命令列表

4.3 权限控制

1
2
3
4
5
6

// sysctl: /proc/sys/kernel/unprivileged_bpf_disabled
// 0 = 允许非特权  1 = 永久禁止  2 = 默认禁止（CONFIG_BPF_UNPRIV_DEFAULT_OFF）

// BPF_MAP_CREATE 和 BPF_PROG_LOAD 需要 CAP_BPF 或 CAP_SYS_ADMIN
if (!capable && (cmd == BPF_MAP_CREATE || cmd == BPF_PROG_LOAD))
    return -EPERM;

五、程序加载与验证器

5.1 加载流程

1
2
3
4
5
6
7
8
9
10
11
12

bpf_prog_load()
  ├── 检查 license（GPL 兼容才能调用 GPL-only helper）
  ├── 检查 prog_type 权限（网络类需 CAP_NET_ADMIN 等）
  ├── bpf_prog_alloc() — 分配 prog 结构
  ├── copy_from_user(insns) — 复制字节码
  ├── bpf_prog_select_runtime() — 选择解释器或 JIT
  ├── bpf_check() — 验证器（verifier.c）
  │     ├── 第一遍：CFG 分析（DAG、无环、可达性）
  │     └── 第二遍：寄存器类型状态追踪
  ├── bpf_prog_load_btf() — 加载关联 BTF
  ├── bpf_prog_alloc_id() — 分配全局 ID
  └── fd_install() — 返回文件描述符

5.2 验证器核心逻辑

verifier.c 中 bpf_check() 是 eBPF 安全的核心：

第一遍 — CFG 验证：

• 程序必须是 DAG（无循环）
• 指令数 ≤ BPF_MAXINSNS（4096，特权用户更高）
• 所有跳转目标合法

第二遍 — 状态追踪：

• 每个寄存器维护类型状态（PTR_TO_CTX、PTR_TO_MAP_VALUE、SCALAR_VALUE 等）
• 追踪算术运算对指针类型的影响
• 检查 helper 调用的参数类型约束
• 检查 map 访问边界（key/value size）
• 检查 null 指针解引用（通过 branch 类型细化）

寄存器类型示例：

1
2
3
4
5
6

程序入口: R1 = PTR_TO_CTX
BPF_MOV64_REG(R2, R10)           → R2 = FRAME_PTR
BPF_ALU64_IMM(ADD, R2, -4)       → R2 = PTR_TO_STACK (offset -4)
BPF_LD_MAP_FD(R1, map_fd)        → R1 = CONST_PTR_TO_MAP
BPF_CALL(map_lookup_elem)        → 检查 arg1=MAP, arg2=STACK key
                                  → R0 = PTR_TO_MAP_VALUE_OR_NULL

Reference 类型追踪：

• PTR_TO_SOCKET_OR_NULL 等内核资源引用
• 必须在程序所有路径上正确释放（如 bpf_sk_release）

5.3 程序类型验证器

每种 BPF_PROG_TYPE 有独立的 bpf_verifier_ops：

1
2
3

static const struct bpf_verifier_ops * const bpf_verifier_ops[] = {
#include <linux/bpf_types.h>  // BPF_PROG_TYPE 宏展开
};

提供：get_func_proto（helper 原型）、is_valid_access（context 访问）、check_attach 等。

六、程序执行引擎

6.1 bpf_prog_run

1
2
3
4
5

// include/linux/filter.h
static __always_inline u32 bpf_prog_run(const struct bpf_prog *prog, const void *ctx)
{
    return prog->bpf_func(ctx, prog->insnsi);
}

• JIT 模式：prog->bpf_func 指向 JIT 编译后的机器码入口
• 解释器模式：prog->bpf_func = __bpf_prog_run，内部调用 ___bpf_prog_run()

6.2 eBPF 解释器

core.c 中 ___bpf_prog_run() 使用 computed goto 跳转表实现高效解释执行：

1
2
3
4
5
6
7
8
9
10
11

static u64 ___bpf_prog_run(u64 *regs, const struct bpf_insn *insn)
{
    static const void * const jumptable[256] = { ... };
select_insn:
    goto *jumptable[insn->code];
    ALU(ADD, +)
    ALU(SUB, -)
    // ... 所有 eBPF 指令
    BPF_JMP | BPF_CALL:  // helper 调用
    BPF_JMP | BPF_EXIT:  // 程序退出，返回 R0
}

6.3 JIT 编译

架构相关 JIT 位于 arch/arm64/net/bpf_jit_comp.c（RK3588）：

• 将 eBPF 指令翻译为 ARM64 机器码
• 处理 tail call、helper 调用、map 访问
• 支持 hardening（常量 blinding）
• 生成 line info 用于 stack trace

控制接口：

1
2
3

/proc/sys/net/core/bpf_jit_enable    # 0=解释器 1=JIT 2=JIT+debug
/proc/sys/net/core/bpf_jit_harden      # hardening 级别
/proc/sys/net/core/bpf_jit_kallsyms    # JIT 代码加入 kallsyms

6.4 Dispatcher — 避免间接调用

dispatcher.c 为多 prog 挂载点生成 multiway branch 代码，将 indirect call 转为 direct call，在 retpoline 启用时显著提升性能。

七、Map 映射类型

7.1 通用 Map

7.2 特殊用途 Map

7.3 网络 Map

八、Helper 辅助函数

8.1 通用 Helper（helpers.c）

8.2 Helper 原型约束

每个 helper 通过 bpf_func_proto 声明参数/返回类型约束，供 verifier 检查：

1
2
3
4
5
6

const struct bpf_func_proto bpf_map_lookup_elem_proto = {
    .func       = bpf_map_lookup_elem,
    .ret_type   = RET_PTR_TO_MAP_VALUE_OR_NULL,
    .arg1_type  = ARG_CONST_MAP_PTR,
    .arg2_type  = ARG_PTR_TO_MAP_KEY,
};

8.3 类型特定 Helper

各 prog type 在各自 verifier ops 的 get_func_proto() 中提供额外 helper，例如：

• XDP：bpf_xdp_adjust_head/meta/room
• Tracing：bpf_probe_read*、bpf_get_stackid
• Cgroup：bpf_get_current_cgroup_id
• LSM：bpf_inode_storage_*

九、BTF 类型系统

9.1 概述

BTF（BPF Type Format）描述 BPF 程序/ map 的数据类型，存储在 ELF .BTF section 或独立加载。

btf.c 功能：

• 解析 BTF type section 和 string section
• 两遍验证（收集 type_id → 检查引用）
• 内核 vmlinux BTF 支持（CONFIG_DEBUG_INFO_BTF）
• CO-RE relocation 处理

9.2 主要用途

9.3 BTF ID 集合

1
2
3
4

// bpf_lsm.c 示例
BTF_SET_START(bpf_lsm_hooks)
#include <linux/lsm_hook_defs.h>  // 自动生成所有 LSM hook 的 BTF ID
BTF_SET_END(bpf_lsm_hooks)

十、程序挂载与 Trampoline

10.1 挂载方式对比

10.2 BPF Trampoline

trampoline.c 实现函数级 BPF 挂载：

1
2
3
4
5
6

被追踪函数入口
  → ftrace direct call
  → bpf_trampoline（跳板代码）
  → BPF_PROG_TYPE_TRACING (fentry)
  → 原始函数（可选）
  → BPF_PROG_TYPE_TRACING (fexit)

支持类型：

• BPF_TRACE_FENTRY — 函数入口
• BPF_TRACE_FEXIT — 函数返回
• BPF_MODIFY_RETURN — 修改返回值

10.3 程序类型与挂载点

十一、Cgroup BPF 与 LSM

11.1 Cgroup BPF

cgroup.c 实现将 BPF 程序附加到 cgroup 层级：

1
2
3
4
5
6
7

cgroup/
  ├── BPF_CGROUP_INET_INGRESS/EGRESS    ← 网络 ingress/egress
  ├── BPF_CGROUP_INET4/6_BIND/CONNECT   ← socket 操作
  ├── BPF_CGROUP_UDP4/6_SENDMSG/RECVMSG
  ├── BPF_CGROUP_SOCK_OPS               ← socket 生命周期
  ├── BPF_CGROUP_DEVICE                 ← 设备访问控制
  └── BPF_CGROUP_SYSCTL                 ← sysctl 访问控制

执行路径：

1
2
3
4
5

// cgroup.c
bpf_prog_run_array_cg(cgrp, atype, ctx, run_prog, retval, ret_flags)
  → 遍历 effective[atype] prog 数组
  → 依次 bpf_prog_run(prog, ctx)
  → 累积返回值（如 -EPERM 拒绝）

11.2 BPF LSM

bpf_lsm.c 为每个 LSM hook 创建 nop 函数 bpf_lsm_<hookname>()，BPF 程序通过 trampoline 挂载：

• 支持 MAC（强制访问控制）策略
• 支持 Audit 策略
• 通过 BTF 匹配 hook 签名
• 部分 hook 通过 cgroup shim 执行

十二、BPF Iterator 与 Link

12.1 BPF Iterator

bpf_iter.c 提供内核对象迭代框架：

• 用户通过 BPF_ITER_CREATE 创建 iterator link
• 读取 /proc/self/fd/<iter_fd> 触发 BPF prog 对每个对象执行
• 预置 target：map、prog、task、cgroup、link

预加载迭代器（preload/）在启动时自动注册 maps.debug 和 progs.debug link。

12.2 bpffs 文件系统

inode.c 实现 bpffs 伪文件系统：

1
2
3

mount -t bpf bpf /sys/fs/bpf
echo <prog_fd> > /sys/fs/bpf/my_prog    # pin prog
cat /sys/fs/bpf/my_prog                  # 获取 fd

支持 pin prog、map、link，实现跨进程共享和持久化。

十三、网络相关 Map

13.1 Devmap — 设备重定向

devmap.c 实现 XDP 帧重定向到指定网络设备：

1
2
3

XDP prog: bpf_redirect_map(devmap, ifindex, 0)
  → 查找 devmap[ifindex]
  → 将 skb/xdp_frame 发送到目标设备 TX 队列

13.2 CPUMAP — 跨 CPU 转发

cpumap.c 实现 XDP 帧转发到其他 CPU 处理：

1
2
3
4

XDP prog: bpf_redirect_map(cpumap, cpu_id, 0)
  → 将帧放入目标 CPU 的 cpumap 队列
  → 目标 CPU kthread 取出并运行 BPF prog
  → 最终通过 devmap 或直接 TX 发送

十四、完整加载执行时序

以 kprobe BPF 程序 为例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

[用户空间 - libbpf]
  bpf_object__open("prog.o")
  bpf_object__load()
    → bpf(BPF_BTF_LOAD)           // 加载 BTF
    → bpf(BPF_MAP_CREATE) × N     // 创建 maps
    → bpf(BPF_PROG_LOAD)          // 加载 prog（含 verifier）
    → bpf(BPF_LINK_CREATE)        // 创建 kprobe link

[内核 - BPF_PROG_LOAD]
  bpf_prog_load()
    → copy insns from userspace
    → bpf_check()                 // verifier 验证
    → bpf_int_jit_compile()       // ARM64 JIT
    → 返回 prog fd

[内核 - BPF_LINK_CREATE]
  link_create()
    → 注册 kprobe/uprobe/tracepoint
    → 关联 prog 到挂载点

[内核 - 运行时触发]
  被 probe 的函数执行
    → kprobe handler
    → bpf_prog_run(prog, ctx)
    → JIT 机器码 / 解释器
    → helper 调用（如 bpf_printk）
    → 返回 R0

[用户空间 - 读取结果]
  读取 trace_pipe / ringbuf map / perf buffer

十五、RK3588 平台调试建议

15.1 确认 BPF 支持

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

# 检查内核配置
zcat /proc/config.gz | grep -E 'BPF|BTF|CGROUP_BPF'

# 关键项（ARM64 RK3588 典型配置）
# CONFIG_BPF_SYSCALL=y
# CONFIG_BPF_JIT=y
# CONFIG_HAVE_EBPF_JIT=y
# CONFIG_DEBUG_INFO_BTF=y
# CONFIG_CGROUP_BPF=y

# 检查 JIT 状态
cat /proc/sys/net/core/bpf_jit_enable   # 应为 1

# 检查 bpffs
mount | grep bpf
ls /sys/fs/bpf/

15.2 常用调试工具

15.3 RK3588 典型应用场景

15.4 注意事项

• RK3588 默认可能启用 CONFIG_BPF_UNPRIV_DEFAULT_OFF，需要 root/CAP_BPF 权限
• big.LITTLE 环境下 per-CPU map 在 A76/A55 核心间独立，注意数据一致性
• JIT 代码位于 module_alloc 区域，可通过 bpftool prog dump jited 查看
• 验证失败时查看 dmesg 或 bpftool prog tracelog 获取详细日志

十六、总结

kernel/bpf 是 Linux 内核 eBPF 子系统的核心实现，其设计要点：

1. Verifier — 静态分析保证安全，是指令级类型检查器而非简单 sandbox
2. Map — 提供 prog 间、内核与用户间的共享状态机制，多种专用 map 适配不同场景
3. JIT — ARM64 JIT 将字节码编译为本地代码，接近原生性能
4. BTF — 类型系统支撑 CO-RE、fentry、struct_ops 等高级特性
5. Link — 统一的挂载生命周期管理
6. Trampoline — 基于 ftrace 的高效函数级挂载

在 RK3588 平台上，eBPF 可用于网络加速（XDP/TC）、容器安全（cgroup/LSM）、内核可观测性（fentry/tracepoint）等，是嵌入式 Linux 系统调优和安全加固的重要工具。

附录：源文件完整清单

kernel/cgroup Cgroup 机制与原理详解

源码路径：rk3588/kernel-6.1/kernel/cgroup/
内核版本：Linux 6.1（RK3588 平台）
平台：RK3588（4×Cortex-A76 + 4×Cortex-A55 big.LITTLE）

该目录实现 Linux cgroup（Control Group） 子系统的核心框架及部分内置控制器。Cgroup 将进程组织成层次化分组，对 CPU、内存、I/O、设备等资源进行限制、隔离与统计，是容器（Docker/LXC）、systemd、Android 资源管控的基础。

说明：cgroup 采用插件化设计。本目录提供统一框架（层级管理、任务迁移、kernfs 接口、统计等），各资源控制器分散在内核其他目录实现，通过 cgroup_subsys 注册接入。

目录

• 一、源码目录结构
• 二、整体架构
• 三、核心数据结构
• 四、Cgroup v1 与 v2
• 五、子系统注册与生命周期
• 六、任务迁移机制
• 七、递归统计 rstat
• 八、本目录内置控制器
• 九、分散实现的控制器
• 十、Cgroup Namespace
• 十一、用户空间接口
• 十二、完整任务加入 Cgroup 时序
• 十三、RK3588 / Android 平台应用
• 十四、总结

一、源码目录结构

1.1 编译单元（Makefile）

1
2
3
4
5
6
7
8

obj-y := cgroup.o rstat.o namespace.o cgroup-v1.o freezer.o

obj-$(CONFIG_CGROUP_FREEZER) += legacy_freezer.o
obj-$(CONFIG_CGROUP_PIDS)      += pids.o
obj-$(CONFIG_CGROUP_RDMA)      += rdma.o
obj-$(CONFIG_CPUSETS)          += cpuset.o
obj-$(CONFIG_CGROUP_MISC)      += misc.o
obj-$(CONFIG_CGROUP_DEBUG)     += debug.o

1.2 子系统清单（cgroup_subsys.h）

所有控制器在 include/linux/cgroup_subsys.h 中枚举：

二、整体架构

2.1 分层模型

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

┌─────────────────────────────────────────────────────────────┐
│                    用户空间                                  │
│   systemd / Docker / crictl / echo > cgroup.procs           │
└──────────────────────────┬──────────────────────────────────┘
                           │ 读写 /sys/fs/cgroup/ (kernfs)
┌──────────────────────────▼──────────────────────────────────┐
│              cgroup.c + cgroup-v1.c (核心框架)                 │
│  cgroup_root │ cgroup │ css_set │ 迁移 │ 挂载 │ 文件接口      │
└──────┬──────────┬──────────┬──────────┬─────────────────────┘
       │          │          │          │
┌──────▼──┐ ┌─────▼────┐ ┌──▼──────┐ ┌─▼──────────────┐
│ cpuset  │ │ cpu/mem  │ │ freezer │ │ pids/rdma/   │
│ (本目录) │ │ (sched/mm)│ │ (本目录)│ │ misc (本目录)│
└──────┬──┘ └─────┬────┘ └──┬──────┘ └─┬──────────────┘
       │          │          │          │
       └──────────┴──────────┴──────────┘
                           │
              ┌────────────▼────────────┐
              │   task_struct           │
              │   task->cgroups (css_set)│
              │   fork/exit 钩子         │
              └─────────────────────────┘

2.2 关键锁

1
2
3
4

// cgroup.c
DEFINE_MUTEX(cgroup_mutex);          // 层级结构修改主锁
DEFINE_SPINLOCK(css_set_lock);       // task->cgroups、css_set 链表
DEFINE_PERCPU_RWSEM(cgroup_threadgroup_rwsem);  // 线程组迁移

2.3 默认层级

1
2
3

// cgroup.c
struct cgroup_root cgrp_dfl_root;   // unified v2 默认层级
LIST_HEAD(cgroup_roots);            // 所有层级根（含 v1 多层级）

• cgroup v2（default hierarchy）：单一统一层级，挂载于 /sys/fs/cgroup
• cgroup v1（legacy）：可多层级，每层级绑定不同控制器组合

三、核心数据结构

3.1 struct cgroup — 控制组节点

1
2
3
4
5
6
7
8
9
10
11
12
13

// include/linux/cgroup-defs.h
struct cgroup {
    struct cgroup_subsys_state self;  // 自身 css（ss == NULL）
    unsigned long flags;              // CGRP_FREEZE, CGRP_FROZEN 等
    int level;                        // 树深度（root = 0）
    struct kernfs_node *kn;           // kernfs 目录节点
    struct cgroup_subsys_state __rcu *subsys[CGROUP_SUBSYS_COUNT];
    u16 subtree_control;              // 子 cgroup 启用的控制器
    u16 subtree_ss_mask;              // 实际生效的控制器掩码
    struct cgroup_root *root;
    struct cgroup *dom_cgrp;          // 域 cgroup（threaded 模式）
    // ...
};

每个 cgroup 在文件系统中对应一个目录（如 /sys/fs/cgroup/system.slice/）。

3.2 struct cgroup_subsys_state (css) — 控制器状态

1
2
3
4
5
6
7
8
9
10
11

struct cgroup_subsys_state {
    struct cgroup *cgroup;            // 所属 cgroup
    struct cgroup_subsys *ss;         // 所属子系统
    struct percpu_ref refcnt;         // 引用计数
    struct list_head sibling;         // 兄弟 css 链表
    struct list_head children;        // 子 css 链表
    struct cgroup_subsys_state *parent;
    int id;                           // 子系统内唯一 ID
    u64 serial_nr;                    // 全局递增序号
    // ...
};

每个 (cgroup, subsystem) 对一个 css 实例。例如启用 memory 控制器的 cgroup 有 memory css。

3.3 struct css_set — 任务 cgroup 成员关系

1
2
3
4
5
6
7
8
9

struct css_set {
    struct cgroup_subsys_state *subsys[CGROUP_SUBSYS_COUNT];  // 各子系统 css 指针
    refcount_t refcount;
    struct css_set *dom_cset;         // 域 css_set（threaded 模式）
    struct cgroup *dfl_cgrp;          // 默认层级 cgroup
    struct list_head tasks;           // 属于此 cset 的任务链表
    struct list_head cgrp_links;      // 与 cgroup 的 M:N 关联
    // ...
};

设计要点：一个任务的 task->cgroups 指向一个 css_set。多个任务可共享同一 css_set（当它们在所有层级上的 cgroup 成员关系完全相同时），fork 时只需增减 css_set 引用计数，避免逐控制器更新。

3.4 struct cgroup_root — 层级根

1
2
3
4
5
6
7
8
9

struct cgroup_root {
    struct kernfs_root *kf_root;      // kernfs 根
    struct cgroup cgrp;               // 根 cgroup
    int hierarchy_id;
    u16 subsys_mask;                  // v1: 挂载的控制器掩码
    unsigned int flags;               // CGRP_ROOT_* 标志
    char release_agent_path[PATH_MAX]; // v1 release agent
    // ...
};

3.5 struct cgroup_subsys — 控制器插件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

struct cgroup_subsys {
    struct cgroup_subsys_state *(*css_alloc)(struct cgroup_subsys_state *parent_css);
    int  (*css_online)(struct cgroup_subsys_state *css);
    void (*css_offline)(struct cgroup_subsys_state *css);
    void (*css_free)(struct cgroup_subsys_state *css);
    int  (*can_attach)(struct cgroup_taskset *tset);
    void (*attach)(struct cgroup_taskset *tset);
    void (*fork)(struct task_struct *task);
    void (*exit)(struct task_struct *task);
    struct cftype *dfl_cftypes;       // v2 接口文件
    struct cftype *legacy_cftypes;    // v1 接口文件
    const char *name;
    bool implicit_on_dfl;             // v2 隐式启用
    bool threaded;                    // 支持 threaded 模式
    // ...
};

3.6 M:N 关系 — cgrp_cset_link

1
2
3

cgroup A ←── cgrp_cset_link ──→ css_set X ←── task 1, task 2
cgroup B ←── cgrp_cset_link ──→ css_set X
cgroup C ←── cgrp_cset_link ──→ css_set Y ←── task 3

一个 css_set 可关联多个 cgroup（v1 多层级），一个 cgroup 也可关联多个 css_set（不同任务组合）。

四、Cgroup v1 与 v2

4.1 对比

4.2 v2 Domain 与 Threaded 模式

• Domain cgroup：资源隔离边界，可启用所有控制器，内部不应直接持有进程（leaf 除外）
• Threaded cgroup：仅支持 cpu、memory、pids、perf_event 等 threaded 控制器，用于线程级分组

通过 cgroup.type 文件设置：domain、domain threaded、threaded。

4.3 v2 控制器启用流程

1
2
3
4
5
6

# 在父 cgroup 启用 memory 和 cpu 控制器供子 cgroup 使用
echo "+memory +cpu" > /sys/fs/cgroup/cgroup.subtree_control

# 在子 cgroup 中设置限制
echo "max 200000" > /sys/fs/cgroup/mygroup/cpu.max
echo "256M" > /sys/fs/cgroup/mygroup/memory.max

五、子系统注册与生命周期

5.1 注册机制

1
2
3
4

// cgroup.c — 编译期生成子系统指针数组
struct cgroup_subsys *cgroup_subsys[] = {
#include <linux/cgroup_subsys.h>   // SUBSYS(cpu) → &cpu_cgrp_subsys
};

每个控制器在各自源文件中定义：

1
2
3
4
5
6
7
8
9
10
11
12

// kernel/sched/core.c
struct cgroup_subsys cpu_cgrp_subsys = {
    .css_alloc   = cpu_css_alloc,
    .css_online  = cpu_css_online,
    .css_offline = cpu_css_offline,
    .css_free    = cpu_css_free,
    .can_attach  = cpu_cgroup_can_attach,
    .attach      = cpu_cgroup_attach,
    .fork        = cpu_cgroup_fork,
    .dfl_cftypes = cpu_files,
    .name        = "cpu",
};

5.2 css 生命周期

1
2
3
4
5
6
7
8
9

cgroup 创建子目录
  → css_alloc(parent_css)        // 分配子 css
  → css_online(css)              // 激活，CSS_ONLINE 置位
  → 用户写入接口文件配置限制

cgroup 删除（rmdir）
  → css_offline(css)             // 停用，拒绝新任务
  → css_released(css)            // 引用归零
  → css_free(css)                // 释放（可能异步 via workqueue）

5.3 任务生命周期钩子

1
2
3
4
5
6
7

// include/linux/cgroup.h
void cgroup_fork(struct task_struct *p);       // fork 时继承 css_set
int  cgroup_can_fork(...);                     // fork 前检查（pids 等）
void cgroup_post_fork(...);                     // fork 后通知控制器
void cgroup_exit(struct task_struct *p);       // 退出时递减计数
void cgroup_release(struct task_struct *p);
void cgroup_free(struct task_struct *p);

六、任务迁移机制

6.1 迁移 API

1
2
3

// 用户写入 cgroup.procs 或 cgroup.threads 触发
int cgroup_attach_task(struct cgroup *dst_cgrp, struct task_struct *leader,
                       bool threadgroup);

6.2 迁移流程

1
2
3
4
5
6
7
8
9
10

cgroup_attach_task()
  ├── cgroup_migrate_add_src()       // 收集源 css_set
  ├── cgroup_migrate_prepare_dst()   // 预创建/查找目标 css_set
  └── cgroup_migrate()
        ├── cgroup_migrate_add_task() // 任务加入 mg_tasks 链表
        └── cgroup_migrate_execute()
              ├── can_attach()        // 各控制器预检查
              ├── css_set_move_task() // 切换 task->cgroups（commit）
              ├── attach()            // 通知控制器迁移完成
              └── post_attach()

核心 commit 点（cgroup_migrate_execute）：

1
2
3
4
5
6
7
8

spin_lock_irq(&css_set_lock);
list_for_each_entry(cset, &tset->src_csets, mg_node) {
    list_for_each_entry_safe(task, tmp_task, &cset->mg_tasks, cg_list) {
        css_set_move_task(task, from_cset, to_cset, true);
        cgroup_freezer_migrate_task(task, from_cset->dfl_cgrp, to_cset->dfl_cgrp);
    }
}
spin_unlock_irq(&css_set_lock);

原子性保证：所有 can_attach() 通过后才会 commit；任一失败则全部回滚。

6.3 常用迁移方式

七、递归统计 rstat

7.1 设计目标

rstat.c 实现 可扩展递归统计（scalable recursive statistics）：

• 每个 cgroup 维护 per-CPU 统计（cgroup_rstat_cpu）
• 写入时仅标记本 cgroup 为 “updated”
• 读取时惰性向上传播到祖先，复杂度 O(活跃子树大小) 而非 O(总子树)

7.2 数据结构

1
2
3
4
5
6
7

struct cgroup_rstat_cpu {
    struct u64_stats_sync bsync;
    struct cgroup_base_stat bstat;       // CPU 时间等基础统计
    struct cgroup_base_stat last_bstat;  // 上次读取快照
    struct cgroup *updated_children;     // 有更新的子 cgroup 链表
    struct cgroup *updated_next;
};

7.3 使用场景

• cgroup.stat — 显示 CPU 使用统计
• memory.current、memory.peak 等（memory 控制器扩展 rstat）
• PSI（Pressure Stall Information）压力指标

八、本目录内置控制器

8.1 Cpuset（cpuset.c）

最复杂的内置控制器（~4,246 行），管理 CPU 和内存节点亲和性：

RK3588 big.LITTLE 场景下，cpuset 可将任务绑定到 A76 或 A55 核心簇。

8.2 Freezer（freezer.c + legacy_freezer.c）

v2 freezer（freezer.c）：

冻结机制：设置 CGRP_FREEZE 标志，对任务发送 SIGSTOP，CGRP_FROZEN 表示实际已冻结。支持递归：所有子 cgroup 都 frozen 时父 cgroup 也标记 frozen。

v1 legacy_freezer（legacy_freezer.c）：独立的 freezer 控制器，freezer.state 文件。

8.3 Pids（pids.c）

限制 cgroup 内进程数量：

fork() 时通过 can_fork() 检查，超限返回 -EAGAIN。

8.4 RDMA（rdma.c）

限制 RDMA 资源使用：

按 cgroup × RDMA 设备维护 resource pool。

8.5 Misc（misc.c）

杂项硬件资源限制（如 AMD SEV/SEV-ES ASID 数量），采用 Limits 分配模型。

8.6 Debug（debug.c）

调试控制器，仅在 cgroup_debug=1 时启用，提供额外诊断接口。

九、分散实现的控制器

9.1 CPU 控制器（kernel/sched/core.c）

与 CFS 调度器深度集成，通过 task_group 实现带宽控制。

9.2 Memory 控制器（mm/memcontrol.c）

通过 mem_cgroup 结构跟踪 page cache、anon、swap 等。

9.3 IO 控制器（block/blk-cgroup.c）

9.4 其他

十、Cgroup Namespace

namespace.c 实现 cgroup namespace（CLONE_NEWCGROUP）：

1
2
3
4
5

struct cgroup_namespace {
    struct ns_common ns;
    struct user_namespace *user_ns;
    struct css_set *root_cset;    // 命名空间内的"根" css_set
};

• 容器内 /proc/self/cgroup 显示相对于 namespace root 的路径
• 创建需要 CAP_SYS_ADMIN
• 与 mount namespace 配合实现容器 cgroup 视图隔离

十一、用户空间接口

11.1 v2 统一接口（每个 cgroup 目录）

11.2 常用操作示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

# 创建 cgroup 并设置内存限制
mkdir /sys/fs/cgroup/myapp
echo "+memory +cpu" > /sys/fs/cgroup/cgroup.subtree_control
echo "256M" > /sys/fs/cgroup/myapp/memory.max
echo "50000 100000" > /sys/fs/cgroup/myapp/cpu.max   # 50ms/100ms = 50% CPU
echo $$ > /sys/fs/cgroup/myapp/cgroup.procs

# 查看 cgroup 路径
cat /proc/self/cgroup

# 冻结 cgroup
echo 1 > /sys/fs/cgroup/myapp/cgroup.freeze

# cpuset 绑定到 CPU 4-7（A76 大核）
echo "4-7" > /sys/fs/cgroup/myapp/cpuset.cpus
echo 0 > /sys/fs/cgroup/myapp/cpuset.mems
echo $$ > /sys/fs/cgroup/myapp/cgroup.procs

11.3 bpffs 与 cgroup BPF

cgroup BPF 程序（kernel/bpf/cgroup.c）可附加到 cgroup 的多种 hook 点（ingress/egress/bind/connect 等），实现网络策略。挂载通过 BPF_LINK_CREATE 或 cgroup 目录下的 BPF 接口。

十二、完整任务加入 Cgroup 时序

以 v2 写入 cgroup.procs 为例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

[用户空间]
  echo 1234 > /sys/fs/cgroup/mygroup/cgroup.procs

[内核 - VFS/kernfs]
  cgroup_procs_write()
    → cgroup_attach_task(mygroup, task, true)

[内核 - 迁移准备]
  cgroup_migrate_add_src(task_css_set(task), mygroup, &mgctx)
  cgroup_migrate_prepare_dst(&mgctx)
    → 查找或创建目标 css_set

[内核 - 预检查]
  cgroup_migrate_execute(&mgctx)
    → memory_can_attach()     // 检查 memory 限制
    → cpu_can_attach()        // 检查 cpu 约束
    → pids_can_attach()       // 检查 pids 限制
    → cpuset_can_attach()     // 检查 CPU 亲和性

[内核 - Commit]
    → css_set_move_task(task, from, to, true)
      → task->cgroups = to_cset
    → cgroup_freezer_migrate_task()  // 处理 freeze 状态

[内核 - 通知控制器]
    → memory_attach()         // 更新 memcg 计数
    → cpu_attach()            // 更新 task_group
    → cpuset_attach()         // 更新 CPU 亲和性 mask

[内核 - 调度影响]
  下次 schedule() 时 task 在新 cgroup 的 CPU 权重/带宽下运行
  内存分配计入新 memcg

十三、RK3588 / Android 平台应用

13.1 典型 cgroup 层级（Android/systemd）

1
2
3
4
5
6
7

/sys/fs/cgroup/
├── init.scope
├── system.slice/
│   ├── docker.service/
│   └── ...
├── user.slice/
└── ...

Android 使用 cgroup v2 管理应用进程资源（通过 libprocessgroup）：

13.2 RK3588 big.LITTLE cpuset 配置

1
2
3
4
5
6
7
8

# 性能组：绑定 4 个 A76 大核 (CPU 4-7)
echo "4-7" > /sys/fs/cgroup/performance/cpuset.cpus

# 节能组：绑定 4 个 A55 小核 (CPU 0-3)
echo "0-3" > /sys/fs/cgroup/background/cpuset.cpus

# 查看有效 CPU
cat /sys/fs/cgroup/mygroup/cpuset.cpus.effective

13.3 调试命令

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

# 查看进程 cgroup  membership
cat /proc/<PID>/cgroup

# 查看 cgroup 内进程
cat /sys/fs/cgroup/<path>/cgroup.procs

# 查看内存使用
cat /sys/fs/cgroup/<path>/memory.current
cat /sys/fs/cgroup/<path>/memory.stat

# 查看 CPU 统计
cat /sys/fs/cgroup/<path>/cpu.stat

# 查看 PSI 压力
cat /sys/fs/cgroup/<path>/memory.pressure
cat /sys/fs/cgroup/<path>/cpu.pressure
cat /sys/fs/cgroup/<path>/io.pressure

13.4 确认配置

1
2

zcat /proc/config.gz | grep -E 'CGROUP|CPUSET|MEMCG|BLK_CGROUP'
mount | grep cgroup

RK3588 典型配置：

• CONFIG_CGROUPS=y
• CONFIG_CGROUP_V2=y（默认 unified hierarchy）
• CONFIG_MEMCG=y
• CONFIG_CGROUP_SCHED=y（cpu 控制器）
• CONFIG_BLK_CGROUP=y（io 控制器）
• CONFIG_CPUSETS=y

十四、总结

kernel/cgroup 是 Linux 资源管控的核心基础设施：

1. 统一框架（cgroup.c）— 层级管理、css_set 优化、任务迁移、kernfs 接口
2. 插件化控制器 — 通过 cgroup_subsys 注册，分散在各子系统实现
3. v2 Unified Hierarchy — 单一层级、按需启用控制器、domain/threaded 模式
4. css_set 共享 — 相同 cgroup 组合的任务共享 css_set，优化 fork 性能
5. 原子迁移 — can_attach → commit → attach 三阶段保证一致性
6. rstat — 高效递归统计，支撑 cgroup.stat 和 PSI

在 RK3588 / Android 平台上，cgroup 是进程资源隔离与限制的基础，与调度器（cpu）、内存管理（memory）、块 I/O（io）深度协同，是容器化和系统资源管控的基石。

附录：源文件完整清单

kernel/debug 内核调试机制与原理详解

源码路径：rk3588/kernel-6.1/kernel/debug/
内核版本：Linux 6.1（RK3588 平台）
平台：RK3588（4×Cortex-A76 + 4×Cortex-A55 big.LITTLE，ARM64）

该目录实现 Linux 内核 KGDB（Kernel GDB） 调试子系统的核心代码。KGDB 允许通过串口或网络，使用主机端 GDB 远程调试运行中的内核；可选的 KDB 前端提供内核内置命令行调试器。二者共享 debug_core.c 提供的异常处理、断点管理、SMP 协调等基础设施。

说明：架构相关代码（断点指令、寄存器读写、异常向量）位于 arch/arm64/kernel/kgdb.c 等目录；串口 I/O 模块位于 drivers/tty/serial/kgdboc.c 等；本目录是调试框架的通用核心。

目录

• 一、源码目录结构
• 二、整体架构
• 三、核心数据结构
• 四、异常进入与 SMP 协调
• 五、GDB Stub 远程协议
• 六、KDB 内置调试器
• 七、断点管理
• 八、I/O 与触发方式
• 九、KDB 与 GDB 模式切换
• 十、完整调试会话时序
• 十一、RK3588 平台配置与使用
• 十二、总结

一、源码目录结构

1.1 编译依赖（Makefile）

1
2

obj-$(CONFIG_KGDB) += debug_core.o gdbstub.o
obj-$(CONFIG_KGDB_KDB) += kdb/

1.2 编译单元

1.3 相关代码分布（本目录外）

二、整体架构

2.1 分层模型

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

┌─────────────────────────────────────────────────────────────┐
│                    主机端调试器                               │
│   GDB (target remote)  /  kdb 命令行                          │
└──────────────────────────┬──────────────────────────────────┘
                           │ 串口 / 网络
┌──────────────────────────▼──────────────────────────────────┐
│              gdbstub.c  /  kdb/kdb_main.c                    │
│         GDB Remote Protocol    │    KDB 命令 REPL             │
└──────────────────────────┬──────────────────────────────────┘
                           │
┌──────────────────────────▼──────────────────────────────────┐
│                   debug_core.c (核心)                         │
│  kgdb_handle_exception │ kgdb_cpu_enter │ 断点 │ SMP roundup   │
└──────────────────────────┬──────────────────────────────────┘
                           │
┌──────────────────────────▼──────────────────────────────────┐
│              arch/arm64/kernel/kgdb.c                        │
│  断点指令 │ pt_regs 读写 │ 单步 │ kgdb_brk_fn 异常处理         │
└─────────────────────────────────────────────────────────────┘

2.2 双前端设计

两者可在运行时通过 kgdb 命令或 GDB 3 转义包互相切换。

2.3 关键全局状态

1
2
3
4
5
6

// debug_core.c
struct debuggerinfo_struct kgdb_info[NR_CPUS];  // 每 CPU 调试上下文
atomic_t kgdb_active;                            // 当前 master CPU
int kgdb_connected;                              // 主机 GDB 是否已连接
struct kgdb_io *dbg_io_ops;                      // 当前 I/O 驱动
int dbg_kdb_mode = 1;                            // 1=KDB, 0=GDB stub

三、核心数据结构

3.1 struct kgdb_state — 异常上下文

1
2
3
4
5
6
7
8
9
10
11
12

// debug_core.h
struct kgdb_state {
    int             ex_vector;      // 异常向量号
    int             signo;          // 信号号（SIGTRAP 等）
    int             err_code;       // 错误码
    int             cpu;            // 触发 CPU
    int             pass_exception; // 是否将异常传回内核
    unsigned long   threadid;       // 当前线程 ID
    long            kgdb_usethreadid;
    struct pt_regs *linux_regs;     // CPU 寄存器
    atomic_t       *send_ready;     // NMI 回调同步
};

3.2 struct debuggerinfo_struct — 每 CPU 状态

1
2
3
4
5
6
7
8
9

struct debuggerinfo_struct {
    void            *debuggerinfo;  // 架构相关调试信息（通常 = pt_regs）
    struct task_struct *task;       // 触发时的 current
    int             exception_state; // DCPU_WANT_MASTER 等标志
    int             ret_state;      // 返回状态
    int             irq_depth;      // 进入时硬中断深度
    int             enter_kgdb;     // 递归进入计数
    bool            rounding_up;    // 是否正在 roundup
};

CPU 状态标志：

3.3 struct kgdb_bkpt — 软件断点

1
2
3
4
5
6

// include/linux/kgdb.h
struct kgdb_bkpt {
    unsigned long   bpt_addr;       // 断点地址
    char            saved_instr[BREAK_INSTR_SIZE];  // 原始指令
    int             state;          // BP_SET / BP_REMOVED / BP_UNDEFINED
};

最多 KGDB_MAX_BREAKPOINTS 个（通常 1000），由 GDB 或 KDB 管理。

3.4 struct kgdb_io — I/O 驱动接口

1
2
3
4
5
6
7
8
9
10

struct kgdb_io {
    const char     *name;
    int             (*read_char)(void);
    void            (*write_char)(u8);
    void            (*flush)(void);
    int             (*init)(void);
    void            (*pre_exception)(void);
    void            (*post_exception)(void);
    int             is_early;       // 是否可用于 early debug
};

通过 kgdb_register_io_module() 注册，典型实现为 kgdboc（串口）。

四、异常进入与 SMP 协调

4.1 主入口

1
2
3
4
5
6
7

// debug_core.c
int kgdb_handle_exception(int evector, int signo, int ecode, struct pt_regs *regs)
{
    // 1. 填充 kgdb_state
    // 2. 检查重入（kgdb_reenter_check）
    // 3. 调用 kgdb_cpu_enter() 进入调试主循环
}

ARM64 上由 kgdb_brk_fn() 在断点异常时调用：

1
2
3
4
5
6

// arch/arm64/kernel/kgdb.c
static int kgdb_brk_fn(struct pt_regs *regs, unsigned long esr)
{
    kgdb_handle_exception(1, SIGTRAP, 0, regs);
    return 0;
}

4.2 kgdb_cpu_enter 流程

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

kgdb_cpu_enter()
  ├── 获取 master 锁 (dbg_master_lock)
  ├── kgdb_roundup_cpus()          // SMP: 通知其他 CPU 停止
  ├── 等待所有 CPU 进入 kgdb 等待态
  ├── dbg_deactivate_sw_breakpoints()  // 临时移除 SW 断点
  ├── 关闭 ftrace (tracing_off)
  └── 主循环:
        if (dbg_kdb_mode)
            kdb_stub(ks)           // KDB 命令行
        else
            gdb_serial_stub(ks)    // GDB 协议
        → 根据返回值切换模式或退出
  ├── dbg_activate_sw_breakpoints()    // 恢复断点
  ├── 释放 slave 锁，等待从 CPU 退出
  └── 恢复 tracing，返回正常执行

4.3 SMP Roundup

多核系统中，一个 CPU 触发调试后需冻结其他 CPU，避免并发修改内核状态：

• Master CPU 获取 dbg_master_lock，设置 kgdb_active
• 通过 IPI/NMI 调用 kgdb_nmicallback() 让从 CPU 进入 spin 等待
• 从 CPU 设置 DCPU_IS_SLAVE，在 cpu_loop 中等待
• 调试结束后释放锁，从 CPU 恢复

可通过内核参数 nokgdbroundup 禁用 roundup（调试用，有风险）。

4.4 递归保护

• exception_level — 防止调试器内部再次触发异常时死锁
• kgdb_info[cpu].enter_kgdb — 每 CPU 进入计数
• kgdb_reenter_check() — 检测双重异常

五、GDB Stub 远程协议

5.1 协议格式

GDB 远程串行协议使用 $<data>#<checksum> 帧格式：

1
2
3

// gdbstub.c
static void get_packet(char *buffer);   // 接收并校验
static void put_packet(char *buffer);   // 发送并附加校验

5.2 主要命令处理

5.3 线程与多任务

GDB stub 支持按线程调试：

• Hg<tid> — 设置当前线程
• Hc<tid> — 设置继续执行的线程
• T<tid> — 检查线程状态
• 配合 /proc 或内核 task 列表遍历所有线程

5.4 架构相关处理

kgdb_arch_handle_exception()（ARM64）处理 c/s 包中的地址参数，设置 PC 并启用/禁用硬件单步。

六、KDB 内置调试器

6.1 命令注册机制

1
2
3
4
5
6
7
8
9
10
11

// kdb_main.c
static struct kdb_cmd kdb_cmds[] = {
    { .name = "md",   .func = kdb_md,   ... },  // 内存显示
    { .name = "mm",   .func = kdb_mm,   ... },  // 内存修改
    { .name = "go",   .func = kdb_go,   ... },  // 继续执行
    { .name = "bt",   .func = kdb_bt,   ... },  // 栈回溯
    { .name = "ps",   .func = kdb_ps,   ... },  // 进程列表
    { .name = "bp",   .func = kdb_bp,   ... },  // 断点
    { .name = "kgdb", .func = kdb_kgdb, ... },  // 切换到 GDB
    // ...
};

命令通过 kdb_register() 加入 kdb_cmds_head 链表；kdb_parse() 解析用户输入并 dispatch。

6.2 常用 KDB 命令

6.3 权限控制

kdb_cmd_enabled（模块参数 cmd_enable）按位控制命令权限：

6.4 启动宏（kdb_cmds）

kdb/kdb_cmds 在 KDB 初始化时执行，预定义诊断宏：

1
2
3

defcmd dumpcommon ...   # summary + cpu + ps + dmesg + bt
defcmd dumpall ...      # dumpcommon + bta
defcmd dumpcpu ...      # dumpcommon + btc

七、断点管理

7.1 软件断点（KGDB 核心）

1
2
3
4
5
6
7

// debug_core.c
kgdb_arch_set_breakpoint(bpt)
  → 保存原始指令到 saved_instr
  → 写入架构断点指令（ARM64: BRK）

kgdb_arch_remove_breakpoint(bpt)
  → 恢复原始指令

进入调试器时 deactivate 所有 SW 断点（避免调试代码自身触发），退出时 activate 恢复。

7.2 KDB 断点（kdb_bp.c）

KDB 独立维护最多 KDB_MAXBPT（16）个断点：

支持延迟断点（bp_delay）和单步恢复机制（SSBPT 标志）。

7.3 Blocklist 保护

启用 CONFIG_KGDB_HONOUR_BLOCKLIST 时，禁止在 kprobe blocklist 中的符号（如异常处理路径上的函数）设置断点，防止递归陷阱。

八、I/O 与触发方式

8.1 串口 I/O（kgdboc）

1
2
3
4

# 内核命令行
kgdboc=ttyFIQ0,115200    # RK3588 常用 FIQ 调试串口
# 或
kgdboc=ttyS2,115200

I/O 驱动通过 kgdb_register_io_module() 注册到 dbg_io_ops。

8.2 触发进入调试器

1
2
3
4
5
6

// debug_core.c
static void sysrq_handle_dbg(int key)
{
    kgdb_breakpoint();  // 触发断点异常
}
register_sysrq_key('g', &sysrq_dbg_op);

8.3 内核参数

九、KDB 与 GDB 模式切换

9.1 KDB → GDB

在 KDB 提示符输入：

1

kdb> kgdb

kdb_stub() 返回 DBG_PASS_EVENT，主循环切换 dbg_kdb_mode = 0，下次迭代进入 gdb_serial_stub()。

9.2 GDB → KDB

GDB 发送转义包 '3'，或 KDB I/O 检测到非 GDB 格式输入时切换。

9.3 主循环切换逻辑

1
2
3
4
5
6
7
8
9
10
11
12
13
14

// debug_core.c — cpu_master_loop
while (1) {
    if (dbg_kdb_mode) {
        error = kdb_stub(ks);
    } else {
        error = gdb_serial_stub(ks);
    }
    if (error == DBG_PASS_EVENT)
        dbg_kdb_mode = !dbg_kdb_mode;   // 切换模式
    else if (error == DBG_SWITCH_CPU_EVENT)
        goto cpu_loop;                   // 切换 CPU
    else
        break;                             // 退出调试
}

十、完整调试会话时序

以 SysRq-g 触发 → GDB 连接 为例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

[用户 / 按键]
  echo g > /proc/sysrq-trigger
    → sysrq_handle_dbg()
    → kgdb_breakpoint()
    → ARM64 BRK 异常
    → kgdb_brk_fn(regs)
    → kgdb_handle_exception(SIGTRAP, regs)

[debug_core — SMP 协调]
  kgdb_cpu_enter()
    → master CPU 获取 dbg_master_lock
    → kgdb_roundup_cpus() — IPI 冻结其他 7 核
    → dbg_deactivate_sw_breakpoints()
    → tracing_off()

[KDB 模式 — 默认]
  kdb_stub(ks)
    → kdb_common_init_state()
    → 显示 kdb> 提示符，等待输入

[用户输入 kgdb 切换]
  kdb> kgdb
    → 返回 DBG_PASS_EVENT
    → dbg_kdb_mode = 0

[GDB Stub 模式]
  gdb_serial_stub(ks)
    → put_packet("S05")  // 通知 GDB: SIGTRAP
    → get_packet() 循环处理 m/M/g/G/c/s/Z/z ...

[主机 GDB]
  (gdb) target remote /dev/ttyUSB0
  (gdb) break some_kernel_func
  (gdb) continue

[继续执行后再次触发]
  → 再次进入 kgdb_handle_exception
  → GDB 收到停止通知，可 inspect 寄存器/内存

[退出调试]
  GDB 发送 'D' (detach) 或 'c' (continue)
    → kgdb_cpu_enter 主循环 break
    → dbg_activate_sw_breakpoints()
    → 释放 slave 锁，从 CPU 恢复
    → 系统正常运行

十一、RK3588 平台配置与使用

11.1 内核配置

1
2
3
4
5
6
7
8
9

zcat /proc/config.gz | grep -E 'KGDB|KDB|DEBUG'

# 典型调试内核配置
# CONFIG_DEBUG_KERNEL=y
# CONFIG_HAVE_ARCH_KGDB=y
# CONFIG_KGDB=y
# CONFIG_KGDB_SERIAL_CONSOLE=y
# CONFIG_KGDB_KDB=y          # 可选
# CONFIG_FRAME_POINTER=y     # 建议，改善栈回溯

ARM64 RK3588 在 arch/arm64/Kconfig 中选择 HAVE_ARCH_KGDB，具体实现在 arch/arm64/kernel/kgdb.c。

11.2 设备树 / 命令行示例

1
2
3

# U-Boot 或 bootargs 追加
console=ttyFIQ0,115200 earlycon=uart8250,mmio32,0xfeb50000 \
  kgdboc=ttyFIQ0,115200 kgdbwait

• ttyFIQ0：Rockchip 平台常用 FIQ 调试串口
• kgdbwait：内核初始化完成后暂停，等待 GDB 连接

11.3 主机端 GDB 连接

1
2
3
4
5
6
7
8

# 假设串口为 /dev/ttyUSB0
aarch64-linux-gnu-gdb vmlinux
(gdb) set serial baud 115200
(gdb) target remote /dev/ttyUSB0
(gdb) bt                    # 栈回溯
(gdb) info registers        # 寄存器
(gdb) x/10i $pc             # 反汇编
(gdb) continue

11.4 无 GDB 时使用 KDB

1
2
3
4
5
6
7
8
9