WEBKT

tmpfs 遭遇大规模死锁文件时，如何安全强制卸载且不污染内核常驻内存？

4 0 0 0

在 Linux 高并发、高负载的生产环境中，tmpfs 因其极高读写性能，常被用作缓存目录、 session 存储或容器内的临时文件系统。然而，由于 tmpfs 的所有数据和元数据都直接驻留在内核的 Page Cache 和 shmem 中，一旦其挂载点遭遇大规模死锁文件（例如：进程处于 D 状态并持有 tmpfs 文件的句柄、多进程并发进行 mmap 与 ftruncate 导致页表锁死锁等），常规的卸载操作将彻底失效。

如果此时简单粗暴地执行强制卸载，或者在未清理干净引用计数的情况下进行垃圾回收，极易引发内核内存泄漏（Memory Leak）、甚至是内核崩溃（Kernel Panic）。本文将从内核 VFS 与内存管理机制出发，深入探讨如何在不破坏内核常驻内存的前提下，安全、彻底地卸载死锁的 tmpfs 挂载点。

一、 为什么常规的“强制卸载”在 tmpfs 上会失效？

在探讨解决方案之前，我们需要理清 umount 在内核层面的工作机理，以及 tmpfs 的特殊性。

1. umount -f（Force）的局限性

许多系统管理员在遇到挂载点繁忙（Busy）时，首选命令是 umount -f。然而，在 Linux 内核源码中，-f（MNT_FORCE）参数主要用于网络文件系统（如 NFS、CIFS）。它的作用是向挂载的主机发送终止请求，并强行中断未完成的网络 I/O 请求。对于像 tmpfs 这样的本地内存文件系统，MNT_FORCE 几乎不起任何作用，内核依然会因为引用计数（refcount）不为零而拒绝卸载，返回 Device or resource busy。

2. umount -l（Lazy）的“内存泄露”陷阱

另一个常用命令是 umount -l（MNT_DETACH）。

  • 工作机制：Lazy Unmount 会立即将指定的挂载点从当前系统的挂载名称空间（Namespace）中孤立出来（Detach），后续新的进程无法再访问该挂载点。
  • 致命隐患：它并没有真正释放底层资源。只有当该挂载点上所有的文件描述符（file descriptor）、目录项缓存（dentry）和索引节点（inode）的引用计数全部降为 0 时，内核才会真正调用 tmpfs 的 kill_litter_super 销毁超级块并释放内存。

如果系统中存在大量处于 D 状态（TASK_UNINTERRUPTIBLE，不可中断睡眠）的死锁进程，这些进程持有的文件句柄无法被释放，那么通过 umount -l 卸载的 tmpfs 占用的内存（包括 Page Cache 和匿名内存页）将永久驻留在内核中，成为无法被 OOM Killer 回收的“僵尸常驻内存”，直至系统重启。

二、 诊断阶段：精准定位死锁源头

要安全卸载 tmpfs，核心任务是将挂载点上所有文件及目录的内核引用计数归零。这需要我们绕过常规的 VFS 路径查找，精准剥离死锁源头。

1. 规避 VFS 挂起：使用 /proc 旁路诊断

当 tmpfs 发生严重死锁时，直接运行 lsof /dev/shm/target 或 fuser -m /dev/shm/target 可能会因为试图获取已死锁的 inode->i_rwsem 信号量而跟着挂起（变成新的 D 状态进程）。

安全的做法是直接扫描 /proc 目录下的进程文件描述符链接：

# 绕过 VFS 路径解析，通过遍历 fd 链接安全查找持有目标挂载点文件的进程
find /proc/[1-9]*/fd/ -type l -lname '/path/to/tmpfs/*' 2>/dev/null | awk -F'/' '{print $3}' | sort -u

同时，排查是否有进程将 tmpfs 上的文件进行了内存映射（Memory Mapping）：

# 查找对目标挂载点有 mmap 行为的进程
grep -l '/path/to/tmpfs' /proc/[1-9]*/maps 2>/dev/null | awk -F'/' '{print $3}' | sort -u

2. 判定死锁状态：分析进程内核栈

获取到 PID 后，通过读取 /proc/[PID]/stack 分析其在内核态的阻塞位置：

cat /proc/12345/stack

常见死锁特征：

  • 若栈顶出现 rwsem_down_write_slowpath 或 mutex_lock，说明进程正在争抢信号量。
  • 若出现 wait_on_page_bit，说明进程在等待 Page Cache 页面的 I/O 锁释放，这在 tmpfs 伴随物理内存极度紧张、发生 Swap 换出死锁时非常常见。

三、 实战：安全强制卸载与内存回收四步法

在确认死锁情况后，严禁直接执行 umount -l。请遵循以下闭环方案，按顺序剥离引用，确保内核常驻内存的安全。

第一步：隔离挂载名称空间（Namespace Isolation）

为了防止在清理期间有新的业务进程或自动化脚本写入该 tmpfs，首先将其从全局 VFS 树中剥离：

# 仅执行 Detach，切断外部新连接，但不销毁超级块
umount -l /path/to/tmpfs

此时，外部访问已被阻断，但死锁进程依然在后台持有旧的挂载实例（vfsmount）。

第二步：非侵入式清理活动进程

对于处于 R（Running）或 S（Interruptible Sleep）状态的进程，直接发送 SIGKILL 信号释放句柄：

# 优雅终止进程（先尝试 SIGTERM，再 SIGKILL）
xargs -a <(find /proc/[1-9]*/fd/ -type l -lname '/path/to/tmpfs/*' 2>/dev/null | awk -F'/' '{print $3}' | sort -u) kill -9

第三步：攻克 D 状态死锁进程（不伤内核的关键）

处于 D 状态的进程无法响应任何信号（包括 kill -9）。直接对其发送信号是无效的，必须采取迂回策略强行解除其对 tmpfs 文件的占用。

方案 A：利用 gdb/ptrace 注入 sys_close（适用于非完全死锁的内核等待）

如果进程处于 TASK_UNINTERRUPTIBLE 但并未完全在内核深度睡眠，可以通过 gdb 强行接管其控制流，注入 close() 系统调用：

# 假设死锁进程 PID 为 12345，其持有的 tmpfs 文件描述符为 fd 4
gdb -p 12345 -batch \
  -ex 'p (int)close(4)' \
  -ex 'detach' \
  -ex 'quit'

原理：通过 ptrace 强行在用户态上下文中执行 close 系统调用，递减内核中 struct file 的引用计数。

方案 B：触发 Cgroup Freezer 强制挂起并尝试唤醒

如果死锁由于 CPU 调度或死循环引发，可以使用 cgroup 的 freezer 子系统将进程强制冻结，再解除冻结。这有时能强行打破内核的锁链条：

# 创建临时 cgroup 节点
mkdir /sys/fs/cgroup/freezer/tmpfs_evict
echo 12345 > /sys/fs/cgroup/freezer/tmpfs_evict/tasks

# 冻结进程
echo FROZEN > /sys/fs/cgroup/freezer/tmpfs_evict/freezer.state
sleep 2
# 恢复进程，尝试激活其信号处理流程或内核锁释放逻辑
echo THAWED > /sys/fs/cgroup/freezer/tmpfs_evict/freezer.state

# 清理 cgroup
rmdir /sys/fs/cgroup/freezer/tmpfs_evict

方案 C：利用内核 sysrq 强制解除挂起（高级手段）

如果死锁位于文件锁（Flock/Posix Lock），可以通过向内核写 sysrq 触发锁清理，或者手动修改 /proc/sys/kernel/hung_task_panic 结合超时逻辑（不推荐在生产单机环境轻易尝试 panic，但可作为高可用集群主备切换的手段）。

第四步：强制释放“孤儿”Shmem 页与内存回收

当所有进程都已脱离对该 tmpfs 的文件引用后，我们需要确认内存是否已经真正释放。由于 tmpfs 基于 shmem（共享内存），有时即使文件被删除、进程退出，底层分配的 Page Cache 页面依然可能因为页表映射未完全解除而残留。

1. 检查 shmem 残留

通过 /proc/meminfo 监控 Shmem 字段：

cat /proc/meminfo | grep -E "Shmem|Cached"

2. 强行触发内核脏页写回与缓存回收

向内核发送指令，强制回收未被引用的页缓存和目录项缓存（dentry）：

# 写入前先将脏数据同步（虽然 tmpfs 没有磁盘，但此操作会强制触发内核 shmem 与 swap 的内部整理）
sync

# 释放 pagecache、dentries 和 inodes 缓存
echo 3 > /proc/sys/vm/drop_caches

3. 强制解除匿名共享内存页

如果由于 mmap 残留导致物理内存未释放，可以临时通过启用并配置系统的 Swap 压力，迫使内核将无引用的僵尸 shmem 页面换出到 Swap，从而腾出宝贵的物理常驻内存（RSS）：

# 临时提高 swappiness 指标，促使内核积极回收 shmem
sysctl -w vm.swappiness=100

# 触发一轮轻微的内存压力测试（例如使用 dd 分配临时内存），迫使内核扫描并驱逐无用 shmem 到 swap
# 随后再关闭 swap 或降低 swappiness
sysctl -w vm.swappiness=60

四、 架构级防御：如何规避下一次 tmpfs 死锁？

靠人工介入处理 tmpfs 死锁终究是治标不治本。在架构设计上，应当引入以下机制进行防御：

  1. 设置合理的 size 限制与 nr_inodes 限制：
    在挂载 tmpfs 时，切忌使用默认大小（默认是物理内存的一半）。必须根据业务实际需求显式指定 size 和最大的 nr_inodes（防止小文件过多耗尽内核 struct inode 内存结构）：

    mount -t tmpfs -o size=2G,nr_inodes=200k,mode=755 tmpfs /path/to/target

  2. 严禁在 tmpfs 上进行高并发、无锁保护的 mmap 写入：
    若业务程序包含大内存映射操作，应设计专门的信号捕获机制，在进程退出前显式调用 munmap。

  3. 利用 Cgroup 限制内存与文件句柄：
    将运行在 tmpfs 上的业务进程置于特定的 cgroup 中，限制其最大 pids 和 memory.limit_in_bytes，防止单个进程行为异常导致整个内核的 Page Cache 被耗尽死锁。

墨客运维 tmpfs内核死锁内存管理

评论点评