自定义Linux 4.7.8内核中cgroup OOM-killer触发内核宕机求助

问题背景 #

你在自定义Linux 4.7.8内核环境中，用cgroups配合libvirt限制qemu-kvm虚拟机集群的内存使用，遇到了一个棘手的问题：当libvirt所属的cgroup内存耗尽触发OOM killer时，直接导致内核宕机。哪怕你把cgroup内存上限设为20GB（远低于系统32GB总内存，且系统无其他负载），这个问题依然会出现。

崩溃日志关键信息 #

你的内核崩溃调用栈指向了memcg（内存控制组）和OOM killer的交互流程，核心日志片段如下：

qemu-system-x86 invoked oom-killer: gfp_mask=0x24000c0(GFP_KERNEL), order=0, oom_score_adj=0
CPU: 1 PID: 15433 Comm: qemu-system-x86 Tainted: G O 4.7.8 #25
...
Call Trace:
[<ffffffff81336719>] dump_stack+0x65/0x8c
[<ffffffff8115fe5f>] dump_header+0x5e/0x286
[<ffffffff811608ce>] oom_kill_process+0xc2/0x487
[<ffffffff811b4039>] mem_cgroup_out_of_memory+0x2c7/0x311
[<ffffffff811b43bb>] mem_cgroup_oom_synchronize+0x1ed/0x27b
[<ffffffff81160ffd>] pagefault_out_of_memory+0x1f/0x76
[<ffffffff810999bf>] mm_fault_error+0x66/0x103
[<ffffffff81099e4c>] __do_page_fault+0x3f0/0x4d8
[<ffffffff8109a043>] do_page_fault+0x26/0x2f
[<ffffffff81a3dca8>] page_fault+0x28/0x30

问题根源分析 #

这是Linux 4.7.x系列内核（非长期支持版本）中memcg子系统与OOM killer交互的已知bug：

• 4.7.x内核的memcg模块在处理cgroup级OOM时，存在页表处理、内存预分配或锁竞争的逻辑漏洞，当qemu这类占用大量虚拟内存的进程触发cgroup OOM时，OOM killer的执行路径会触发内核空指针或非法内存访问，直接导致panic。
• 你的内核标记为Tainted: G O，说明存在自定义补丁或第三方模块，这可能加重了bug的触发概率——如果自定义补丁修改了memcg或内存管理相关逻辑，可能引入额外的冲突。

解决方案 #

1. 优先升级到LTS内核（最彻底的解决方式）

Linux 4.7.x是非LTS版本，官方早已停止维护，memcg的大量OOM相关bug在4.9及以上的LTS版本中被完全修复。建议你升级到**4.9.100+**或更高的LTS内核版本，不仅能解决这个宕机问题，还能获得更好的稳定性和安全性。

2. 临时规避措施（无法升级内核时）

• 禁用cgroup级OOM killer：
  给libvirt对应的cgroup设置memory.oom_control参数，关闭OOM killer，转而让内核优先回收内存：

  echo 1 > /sys/fs/cgroup/memory/libvirt/memory.oom_control
  

  注意：这会让内存耗尽的qemu进程被阻塞（而非杀死），需要你监控虚拟机内存使用，避免出现长时间阻塞影响业务。
• 细化内存限制：
  不要只给整个虚拟机集群设置cgroup内存上限，给每个单独的qemu虚拟机配置更精细的内存配额（通过libvirt的memory.max参数），减少单个进程瞬间耗尽cgroup内存的概率。
• 排查自定义补丁：
  如果你给4.7.8内核添加了自定义补丁，先移除memcg、OOM或内存管理相关的补丁，重新编译内核测试，确认是否是补丁引入的冲突。

3. 手动移植补丁（适合内核定制场景）

如果必须保留4.7.8内核，可以从Linux内核git仓库中查找4.7.x到4.9之间修复memcg OOM panic的补丁，手动移植到你的自定义内核中。重点关注以下类型的commit：

• 修复mem_cgroup_out_of_memory中错误处理逻辑的补丁
• 修复OOM killer在cgroup场景下页表处理漏洞的补丁

内容的提问来源于stack exchange，提问作者igalvez