SLUB 调试功能SLAB_STORE_USER的核心数据结构用来记录“谁在什么时候、在哪个 CPU 上、以什么调用栈操作了某个对象”。一、整体定位/* * Tracking user of a slab. */ #define TRACK_ADDRS_COUNT 16 struct track { unsigned long addr; /* Called from address */ #ifdef CONFIG_STACKDEPOT depot_stack_handle_t handle; #endif int cpu; /* Was running on cpu */ int pid; /* Pid context */ unsigned long when; /* When did the operation occur */ };SLAB_STORE_USER是前面提过的调试标志之一也属于DEBUG_METADATA_FLAGS。开启后SLUB 会为每个对象关联一个或多个struct track记录对该对象最近一次分配和释放的现场信息。这样当出现内存泄漏对象一直没释放可看分配者是谁。非法释放释放了不该释放的地址可对比分配/释放记录。use-after-free对象被释放后又被使用可看释放者和当前使用者。重复释放同一对象被释放两次。就能通过/sys/kernel/slab/cache/alloc_traces、free_traces或slabinfo查看这些跟踪信息。二、TRACK_ADDRS_COUNT 16#define TRACK_ADDRS_COUNT 16在没有CONFIG_STACKDEPOT的情况下SLUB 会用固定大小的地址数组保存调用栈最多 16 个返回地址struct track { ... unsigned long addrs[TRACK_ADDRS_COUNT]; // 老式实现里的字段 };你贴的这段是较新版本调用栈不再内嵌在struct track里而是交给CONFIG_STACKDEPOT统一存储TRACK_ADDRS_COUNT仍然作为备选无 STACKDEPOT 时的栈深上限保留。为什么是 16调用栈深度与元数据大小之间的折中太浅抓不到完整调用链定位困难。太深每个 track 占用空间大调试元数据爆炸容易抬高 slab order正是DEBUG_METADATA_FLAGS关心的问题。16 层对绝大多数内核分配路径足够。三、字段逐个解析1.unsigned long addr; /* Called from address */记录调用发生的返回地址即调用kmalloc/kfree的那条指令的下一条地址。最直接、最省空间的定位信息拿到这个地址用addr2line、gdb、faddr2line脚本就能知道是哪个函数、哪一行调用的。即使没有完整调用栈仅凭addr也能定位大部分问题。2.#ifdef CONFIG_STACKDEPOT depot_stack_handle_t handle; #endif开启CONFIG_STACKDEPOT时调用栈由stack depot统一去重存储struct track里只存一个句柄depot_stack_handle_t而非 16 个地址。好处大幅节省内存相同调用栈只存一份多个对象共享同一句柄。栈深不受 16 限制stack depot 可存更深、更完整的栈。便于统计可以按栈聚合“哪个调用路径分配了最多对象”。无CONFIG_STACKDEPOT时该字段不存在退化为内嵌地址数组TRACK_ADDRS_COUNT上限。这是新旧两种实现的条件编译切换点。3.int cpu; /* Was running on cpu */记录操作发生时所在的 CPU 编号。用途分析是否集中在某个 CPUper-CPU 缓存行为、CPU 亲和性问题。结合pid判断是进程上下文还是中断/软中断上下文中断里pid通常为 0 或特殊值。排查多 CPU 竞争导致的问题。4.int pid; /* Pid context */记录操作发生时的进程 PIDcurrent-pid。用途定位是哪个进程在分配/释放。若为 0通常表示发生在中断、软中断或内核线程上下文取决于版本内核线程有自己的 pid。内存泄漏分析时可看“某个进程持续分配却不释放”。5.unsigned long when; /* When did the operation occur */记录操作发生的时间戳通常是jiffies或local_clock()之类的值。用途计算“对象存活了多久”辅助判断泄漏长时间未释放。对比分配和释放的时间顺序判断 use-after-free、重复释放。结合cpu/pid还原时间线。四、struct track在 SLUB 里的使用一个开启SLAB_STORE_USER的缓存通常会为每个对象保存两个 trackstruct track { ... }; // 每个对象对应 // track[0]最近一次分配alloc现场 // track[1]最近一次释放free现场set_track(s, p, TRACK_ALLOC)在分配时写入分配现场。set_track(s, p, TRACK_FREE)在释放时写入释放现场。查询时对比两个 track就能回答“谁分配的、谁释放的、何时、在哪个 CPU/进程”。这些 track 数据通常存在对象外部slab 页的元数据区或独立数组因为内嵌进对象会破坏对象布局。具体存放位置随版本不同早期放在struct page的freelist附近较新版本有专门的元数据管理。内存开销struct track单个大小大致无 STACKDEPOTaddr(8) addrs[16](128) cpu(4) pid(4) when(8) ≈152 字节以上。有 STACKDEPOTaddr(8) handle(4) cpu(4) pid(4) when(8) ≈28 字节。每对象两份开销可观——这正是SLAB_STORE_USER被列入DEBUG_METADATA_FLAGS、会被slab_debugO按 order 情况禁用的原因。五、与其他调试标志的关系标志与struct track的关系SLAB_STORE_USER直接使用struct track记录分配/释放者SLAB_TRACE依赖SLAB_STORE_USER的 track 数据打印跟踪日志
SLUB 调试功能SLAB_STORE_USER的核心数据结构用来记录“谁在什么时候、在哪个 CPU 上、以什么调用栈操作了某个对象”。一、整体定位/* * Tracking user of a slab. */ #define TRACK_ADDRS_COUNT 16 struct track { unsigned long addr; /* Called from address */ #ifdef CONFIG_STACKDEPOT depot_stack_handle_t handle; #endif int cpu; /* Was running on cpu */ int pid; /* Pid context */ unsigned long when; /* When did the operation occur */ };SLAB_STORE_USER是前面提过的调试标志之一也属于DEBUG_METADATA_FLAGS。开启后SLUB 会为每个对象关联一个或多个struct track记录对该对象最近一次分配和释放的现场信息。这样当出现内存泄漏对象一直没释放可看分配者是谁。非法释放释放了不该释放的地址可对比分配/释放记录。use-after-free对象被释放后又被使用可看释放者和当前使用者。重复释放同一对象被释放两次。就能通过/sys/kernel/slab/cache/alloc_traces、free_traces或slabinfo查看这些跟踪信息。二、TRACK_ADDRS_COUNT 16#define TRACK_ADDRS_COUNT 16在没有CONFIG_STACKDEPOT的情况下SLUB 会用固定大小的地址数组保存调用栈最多 16 个返回地址struct track { ... unsigned long addrs[TRACK_ADDRS_COUNT]; // 老式实现里的字段 };你贴的这段是较新版本调用栈不再内嵌在struct track里而是交给CONFIG_STACKDEPOT统一存储TRACK_ADDRS_COUNT仍然作为备选无 STACKDEPOT 时的栈深上限保留。为什么是 16调用栈深度与元数据大小之间的折中太浅抓不到完整调用链定位困难。太深每个 track 占用空间大调试元数据爆炸容易抬高 slab order正是DEBUG_METADATA_FLAGS关心的问题。16 层对绝大多数内核分配路径足够。三、字段逐个解析1.unsigned long addr; /* Called from address */记录调用发生的返回地址即调用kmalloc/kfree的那条指令的下一条地址。最直接、最省空间的定位信息拿到这个地址用addr2line、gdb、faddr2line脚本就能知道是哪个函数、哪一行调用的。即使没有完整调用栈仅凭addr也能定位大部分问题。2.#ifdef CONFIG_STACKDEPOT depot_stack_handle_t handle; #endif开启CONFIG_STACKDEPOT时调用栈由stack depot统一去重存储struct track里只存一个句柄depot_stack_handle_t而非 16 个地址。好处大幅节省内存相同调用栈只存一份多个对象共享同一句柄。栈深不受 16 限制stack depot 可存更深、更完整的栈。便于统计可以按栈聚合“哪个调用路径分配了最多对象”。无CONFIG_STACKDEPOT时该字段不存在退化为内嵌地址数组TRACK_ADDRS_COUNT上限。这是新旧两种实现的条件编译切换点。3.int cpu; /* Was running on cpu */记录操作发生时所在的 CPU 编号。用途分析是否集中在某个 CPUper-CPU 缓存行为、CPU 亲和性问题。结合pid判断是进程上下文还是中断/软中断上下文中断里pid通常为 0 或特殊值。排查多 CPU 竞争导致的问题。4.int pid; /* Pid context */记录操作发生时的进程 PIDcurrent-pid。用途定位是哪个进程在分配/释放。若为 0通常表示发生在中断、软中断或内核线程上下文取决于版本内核线程有自己的 pid。内存泄漏分析时可看“某个进程持续分配却不释放”。5.unsigned long when; /* When did the operation occur */记录操作发生的时间戳通常是jiffies或local_clock()之类的值。用途计算“对象存活了多久”辅助判断泄漏长时间未释放。对比分配和释放的时间顺序判断 use-after-free、重复释放。结合cpu/pid还原时间线。四、struct track在 SLUB 里的使用一个开启SLAB_STORE_USER的缓存通常会为每个对象保存两个 trackstruct track { ... }; // 每个对象对应 // track[0]最近一次分配alloc现场 // track[1]最近一次释放free现场set_track(s, p, TRACK_ALLOC)在分配时写入分配现场。set_track(s, p, TRACK_FREE)在释放时写入释放现场。查询时对比两个 track就能回答“谁分配的、谁释放的、何时、在哪个 CPU/进程”。这些 track 数据通常存在对象外部slab 页的元数据区或独立数组因为内嵌进对象会破坏对象布局。具体存放位置随版本不同早期放在struct page的freelist附近较新版本有专门的元数据管理。内存开销struct track单个大小大致无 STACKDEPOTaddr(8) addrs[16](128) cpu(4) pid(4) when(8) ≈152 字节以上。有 STACKDEPOTaddr(8) handle(4) cpu(4) pid(4) when(8) ≈28 字节。每对象两份开销可观——这正是SLAB_STORE_USER被列入DEBUG_METADATA_FLAGS、会被slab_debugO按 order 情况禁用的原因。五、与其他调试标志的关系标志与struct track的关系SLAB_STORE_USER直接使用struct track记录分配/释放者SLAB_TRACE依赖SLAB_STORE_USER的 track 数据打印跟踪日志
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
