终于,困扰的Linux 调测中最最让开发者头疼的 bug 有解了

2023-12-19 12:40

本文主要是介绍终于,困扰的Linux 调测中最最让开发者头疼的 bug 有解了,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

​一、背景

一直以来,内核内存调测领域一直持续存在着两大行业难题: "内存被改" 和 "内存泄漏"。内存问题行踪诡异、飘忽不定,在 Linux 内核的调测问题中,是最让开发者头疼的 bug 之一,因为内存问题往往发生故障的现场已经是第 N 现场了,尤其是在生产环境上出现,截止目前并没有一个很有效的方案能够进行精准的线上 debug,导致难以排查、耗时耗力。接下来让我们来分别看一下"内存被改" 和 "内存泄漏"这两大难题为什么难。

1.1 内存被改

Linux 的用户态的每个进程都单独拥有自己的虚拟内存空间,由 TLB 页表负责映射管理,从而实现进程间互不干扰的隔离性。然而,在内核态中,所有内核程序共用同一片内核地址空间,这就导致内核程序在分配和使用内存时必须小心翼翼。

​出于性能考虑,内核中绝大多数的内存分配行为都是直接在线性映射区划出一块内存归自己使用,并且对于分配后具体的使用行为没有监控和约束。线性映射区的地址只是对真实物理地址做了一个线性偏移,几乎可以视同直接操作物理地址,并且在内核态是完全开放共享的。这意味着如果内核程序的行为不规范,将可能污染到其他区域的内存。这会引起许多问题,严重的情况下直接会导致宕机。

**一个典型的场景例子:**现在我们假设用户 A 向内存分配系统申请到了 0x00 到 0x0f 这块地址,但这只是口头上的“君子协定”,A不必强制遵守。由于程序缺陷,A 向隔壁的 0x10 写入了数据,而 0x10 是用户 B 的地盘。当B试图读取自己地盘上的数据的时候,就读到了错误的数据。如果这里原本存着数值,就会出现计算错误从而引起各种不可预估的后果,如果这里原本是个指针,那整个内核就可能直接宕机了。

​上述的例子被称为越界访问(out-of-bound),即用户 A 访问了本不属于 A 的地址。内存被改的其他情况还有释放后使用(use-after-free)、无效释放(invalid-free)等。这些情况就想成 A 释放了这片空间后,内核认为这片已经空闲了从而分配给 B 用,然后 A 又杀了个回马枪。例如,我们可以通过以下的模块代码模拟各种内存修改的例子:

//out-of-bound
char *s = kmalloc(8, GFP_KERNEL);
s[8] = '1';
kfree(s);//use-after-free
char *s = kmalloc(8, GFP_KERNEL);
kfree(s);
s[0] = '1';//double-free
char *s = kmalloc(8, GFP_KERNEL);
kfree(s);
kfree(s);
复制代码

1.1.1 为什么调测难

在上面的例子中,宕机最后将会由用户 B 引发,从而产生的各种日志记录和 vmcore 都会把矛头指向 B。也就是说,宕机时已经是问题的第二现场了,距离内存被改的第一现场存在时间差,此时 A 可能早已销声匿迹。这时内核开发者排查了半天,认为 B 不应该出现这个错误,也不知道为什么 B 的那片内存会变成意料之外的值,就会怀疑是内存被其他人改了,但是寻找这个“其他人”的工作是很艰难的。如果运气好,宕机现场还能找出线索(例如犯人还呆在旁边,或是犯人写入的值很有特征),又或者发生了多次相似宕机从而找到关联等等。但是,也存在运气不好时没有线索(例如犯人已经释放内存消失了),甚至主动复现都困难的情况(例如隔壁没人,修改了无关紧要的数据,或者修改完被正主覆写了等等)。

​1.1.2 现有方案的局限性

Linux 社区为了调试内存被改的问题,先后引入了 SLUB DEBUG、KASAN、KFENCE等解决方案。

​但这些方案都存在不少局限性:

  • SLUB DEBUG 需要传入 boot cmdline 后重启,也影响不小的 slab 性能,并且只能针对 slab 场景;
  • KASAN 功能强大,同时也引入了较大的性能开销,因此不适用于线上环境;后续推出的 tag-based 方案能缓解开销,但依赖于 Arm64 的硬件特性,因此不具备通用性;
  • KFENCE 相对来讲进步不少,可在生产环境常态化开启,但它是以采样的方式极小概率地发现问题,需要大规模集群开启来提升概率。而且只能探测 slab 相关的内存被改问题。

1.2 内存泄漏

相对内存被改,内存泄漏的影响显得更为“温和”一些,它会慢慢蚕食系统的内存。与大家所熟知的内存泄漏一样,这是由于程序只分配内存而忘记释放引起的。

​例如,以下模块代码可以模拟内存泄漏:

char *s;
for (;;) {s = kmalloc(8, GFP_KERNEL);ssleep(1);
}
复制代码

1.2.1 为什么调测难

由于用户态程序有自己的独立地址空间管理,问题可能还算好定位(至少一开top 能看见哪个进程吃了一堆内存);而内核态的内存搅在一起,使得问题根源难以排查。开发者可能只能通过系统统计信息观察到某一种内存类型(slab/page)的占用在增长,却找不到具体是谁一直在分配内存而不释放。这是因为内核对于线性映射区的分配是不做记录的,也无从得知每块内存的主人是谁。

1.2.2 现有方案的局限性

Linux 社区在内核中引入了 kmemleak 机制,定期扫描检查内存中的值,是否存在指向已分配区域的指针。kmemleak 这种方法不够严谨,也不能部署于线上环境,并且存在不少 false-positive 问题,因此定位不太精确。另外,在用户态,阿里云自研运维工具集 sysAK 中也包含针对内存泄漏的探测。它通过动态采集分配/释放的行为,结合内存相似性检测,在某些场景下可以实现生产环境的内存泄露问题的精准排查。

二、解决方案

出现内存问题时,如果 vmcore 没有捕获到第一现场,无法发现端倪,这时内核同学的传统做法是切换到 debug 内核使用 KASAN 线下调试。然而线上环境复杂,有些十分隐蔽的问题无法在线下稳定复现,或者在线上时本身就属于偶发。这类棘手的问题往往只能搁置,等待下一次出现时期望能提供更多线索。因此,我们看到了 KFENCE 本身的灵活性,对它进行改进,让它成为一个能灵活调整用于线上/线下的内存问题调试工具。

当前最新的 KFENCE 技术优点是可以灵活调节性能开销(以采样率,即捕获bug的概率为代价),可不更换内核而通过重启的方式开启;而缺点则是捕获概率太小,以及对于线上场景来说重启也比较麻烦。

我们基于 KFENCE 技术的特点,进行了功能增强,并加上一些全新的设计,使其支持全量监控及动态开关,适用于生产环境,并发布在了龙蜥社区的Linux 5.10 分支,具体的实现有:

  • 可以在生产环境的kernel动态开启和动态关闭。
  • 功能关闭时无任何性能回退。
  • 能够100% 捕获slab/order-0 page的out-of-bound、memory corruption, use-after-free、 invaild-free 等故障。
  • 能够精准捕获问题发生的第一现场(从这个意义上来看,可以显著加速问题的复现时间)。
  • 支持 per-slab 开关,避免过多的内存和性能开销。
  • 支持 slab/page 内存泄露问题的排查。

对具体技术细节感兴趣的同学可访问龙蜥社区的内核代码仓库阅读相关源码和文档(链接见文末)。

2.1 使用方法

2.1.1 功能开启

  • (可选)配置按 slab 过滤

访问 /sys/kernel/slab//kfence_enable 对每个 slab 单独开关访问 /sys/module/kfence/parameters/order0_page 控制对于order-0 page 的监控开关

  • 采样模式

用户既可以设置启动命令行 kfence.sample_interval=100 并重启来设置系统启动时直接开启 KFENCE(upstream 原版用法),也可以在系统启动后通过 echo 100 > /sys/module/kfence/parameters/sample_interval 手动打开 KFENCE 的采样功能。

  • 全量模式

首先我们需要对池子大小进行配置。池子大小的估算方法:一个 object 约等于 2 个 page(也就是 8KB)。

考虑将 TLB 页表分裂成PTE粒度对周围的影响,最终的池子大小会按 1GB 向上对齐。(object 个数会自动按 131071 向上对齐)

如果配置了 slab 过滤功能,可以先不做修改,默认开启 1GB 观察情况。

如果没配置过滤又需要全量监控,个人建议先开个 10GB 观察情况。

决定好大小之后,将相应数字写入/sys/module/kfence/parameters/num_objects 中。最后通过设置 sample_interval为-1 来开启。(当然也可以把这俩参数写在启动命令行里,开机即启动)

**如何观察情况:**kfence 启动后读取 /sys/kernel/debug/kfence/stats 接口,如果两项 currently slab/page allocated 之和接近你设置的 object_size,说明池子大小不够用了,需要扩容(先往 sample_interval 写 0 关闭,再改 num_objects,最后往 sample_interval 写 -1 开启)。

2.1.2 内存被改

​2.1.3 内存泄漏

2.2 使用效果

对于内存被改,抓到该行为后会在 dmesg 打印现场的调用栈。从触发现场到该内存的分配/释放情况一应俱全,从而帮助精准定位问题。

​对于内存释放,可配合用户态脚本扫描 /sys/kernel/debug/kfence/objects 中活跃的内存(只有 alloc 没有 free 的记录),找出最多的相同调用栈。

实战演示详见视频回放(链接见文末)。

2.3 性能影响

2.3.1 hackbench

我们使用 ecs 上的裸金属机器进行测试,104vcpu 的 Intel Xeon(Cascade Lake) Platinum 8269CY。使用 hackbench 将线程设满(104),根据不同的采样时间测得性能如下:

​可以看到,在采样间隔设置比较大(例如默认100ms)时,KFENCE 几乎不产生影响。如果采样间隔设置得比较激进,就能以不大的性能损失换取更高的捕获 bug 成功率。需要指出的是,hackbench 测试也是 upstream KFENCE 作者提到的他使用的 benchmark,该 benchmark 会频繁分配内存,因此对kfence较为敏感。该测试用例可以反映 kfence 在较坏情况下的表现,对具体线上环境的性能影响还需因业务而定。

2.3.2 sysbench mysql

使用环境同上,使用 sysbench 自带 oltp.lua 脚本设置 16 线程进行测试。分别观察吞吐(tps/qps)和响应时间 rt 的平均值和 p95 分位。

​可以看到,在采样模式下对该 mysql 测试的业务场景影响微乎其微,全量模式下则会对业务产生可见的影响(本例中约 7%),是否开启全量模式需要结合实际场景具体评估。需要指出的是,本测试开启了全量全抓的模式,如果已知有问题的 slab 类型,可以配合过滤功能进一步缓解 kfence 带来的额外开销。

三、总结

通过在Anolis 5.10 内核中增强 kfence 的功能,我们实现了一个线上的、精准的、灵活的、可定制的内存调试解决方案,可以有效地解决线上内核内存被改和内存泄露这两大难题,同时也为其添加了全量工作模式来确保在调试环境快速抓到 bug 的第一现场。

当然,KFENCE 增强方案也存在一些缺点:

  • 理论上的覆盖场景不全

例如,对于全局/局部变量、dma 硬件直接读写、复合页、野指针等场景无法支持。然而,根据我们的内存问题的数据统计,在线上实际出现的问题里,全都是 slab和order-0 page 相关的内存问题,说明本文的解决方案在覆盖面上对于目前的线上场景已经足够。

  • 内存开销大

目前可以通过支持 per-slab 单独开关、控制 interval 等手段极大地缓解,接下来我们也有计划开发更多的应对内存开销大的优化和稳定性兜底工作。


作者:阿里云云栖号
链接:https://juejin.cn/post/7095578922854645767
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

这篇关于终于,困扰的Linux 调测中最最让开发者头疼的 bug 有解了的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/512191

相关文章

linux-基础知识3

打包和压缩 zip 安装zip软件包 yum -y install zip unzip 压缩打包命令: zip -q -r -d -u 压缩包文件名 目录和文件名列表 -q:不显示命令执行过程-r:递归处理,打包各级子目录和文件-u:把文件增加/替换到压缩包中-d:从压缩包中删除指定的文件 解压:unzip 压缩包名 打包文件 把压缩包从服务器下载到本地 把压缩包上传到服务器(zip

Linux 网络编程 --- 应用层

一、自定义协议和序列化反序列化 代码: 序列化反序列化实现网络版本计算器 二、HTTP协议 1、谈两个简单的预备知识 https://www.baidu.com/ --- 域名 --- 域名解析 --- IP地址 http的端口号为80端口,https的端口号为443 url为统一资源定位符。CSDNhttps://mp.csdn.net/mp_blog/creation/editor

【Python编程】Linux创建虚拟环境并配置与notebook相连接

1.创建 使用 venv 创建虚拟环境。例如,在当前目录下创建一个名为 myenv 的虚拟环境: python3 -m venv myenv 2.激活 激活虚拟环境使其成为当前终端会话的活动环境。运行: source myenv/bin/activate 3.与notebook连接 在虚拟环境中,使用 pip 安装 Jupyter 和 ipykernel: pip instal

Linux_kernel驱动开发11

一、改回nfs方式挂载根文件系统         在产品将要上线之前,需要制作不同类型格式的根文件系统         在产品研发阶段,我们还是需要使用nfs的方式挂载根文件系统         优点:可以直接在上位机中修改文件系统内容,延长EMMC的寿命         【1】重启上位机nfs服务         sudo service nfs-kernel-server resta

【Linux 从基础到进阶】Ansible自动化运维工具使用

Ansible自动化运维工具使用 Ansible 是一款开源的自动化运维工具,采用无代理架构(agentless),基于 SSH 连接进行管理,具有简单易用、灵活强大、可扩展性高等特点。它广泛用于服务器管理、应用部署、配置管理等任务。本文将介绍 Ansible 的安装、基本使用方法及一些实际运维场景中的应用,旨在帮助运维人员快速上手并熟练运用 Ansible。 1. Ansible的核心概念

Linux服务器Java启动脚本

Linux服务器Java启动脚本 1、初版2、优化版本3、常用脚本仓库 本文章介绍了如何在Linux服务器上执行Java并启动jar包, 通常我们会使用nohup直接启动,但是还是需要手动停止然后再次启动, 那如何更优雅的在服务器上启动jar包呢,让我们一起探讨一下吧。 1、初版 第一个版本是常用的做法,直接使用nohup后台启动jar包, 并将日志输出到当前文件夹n

[Linux]:进程(下)

✨✨ 欢迎大家来到贝蒂大讲堂✨✨ 🎈🎈养成好习惯,先赞后看哦~🎈🎈 所属专栏:Linux学习 贝蒂的主页:Betty’s blog 1. 进程终止 1.1 进程退出的场景 进程退出只有以下三种情况: 代码运行完毕,结果正确。代码运行完毕,结果不正确。代码异常终止(进程崩溃)。 1.2 进程退出码 在编程中,我们通常认为main函数是代码的入口,但实际上它只是用户级

【Linux】应用层http协议

一、HTTP协议 1.1 简要介绍一下HTTP        我们在网络的应用层中可以自己定义协议,但是,已经有大佬定义了一些现成的,非常好用的应用层协议,供我们直接使用,HTTP(超文本传输协议)就是其中之一。        在互联网世界中,HTTP(超文本传输协议)是一个至关重要的协议,他定义了客户端(如浏览器)与服务器之间如何进行通信,以交换或者传输超文本(比如HTML文档)。

如何编写Linux PCIe设备驱动器 之二

如何编写Linux PCIe设备驱动器 之二 功能(capability)集功能(capability)APIs通过pci_bus_read_config完成功能存取功能APIs参数pos常量值PCI功能结构 PCI功能IDMSI功能电源功率管理功能 功能(capability)集 功能(capability)APIs int pcie_capability_read_wo