bind mount本质是VFS层的路径重定向，绑定源与目标共享同一inode；它不复制数据、不依赖底层文件系统类型，但非递归绑定默认不包含子挂载点，递归需显式加--rbind。
Linux 中目录绑定挂载（bind mount）本身不会直接导致“死循环”，但若配置不当或与挂载传播（mount propagation）机制叠加，可能引发递归挂载、路径解析异常、ls/cd 卡死等表现类似“死循环”的现象。这类问题本质是内核 VFS 层在解析路径时陷入无限嵌套或阻塞等待，并非程序级的 while(true) 循环。
检查是否形成递归 bind mount 链路
递归挂载是最常见的诱因：例如将 /mnt/data bind mount 到 /mnt/data/sub，又把 /mnt/data/sub 再 bind 到 /mnt/data/sub/nested……最终导致内核在遍历路径时反复跳转，无法收敛。
- 运行
findmnt -D /mnt/data查看该路径下是否存在子挂载（submounts），重点关注TARGET列是否出现自身路径或其子目录 - 用
mount | grep 'bind'筛出所有 bind 类型挂载，人工检查源（source）与目标（target）是否存在父子包含关系 - 特别注意 systemd 或容器运行时自动生成的 bind mount（如
/proc、/sys在容器内的重复挂载），它们可能隐式触发传播链
验证挂载传播模式是否引发意外级联
若父挂载点设为 shared，而你在其下做了 bind mount，新挂载会自动传播到所有共享 peer，可能无意中把同一目录反复挂载进不同命名空间，造成路径解析混乱。
- 执行
findmnt -o TARGET,PROPAGATION /mnt/data查看传播类型；若显示shared，需警惕 - 临时禁用传播：运行
sudo mount --make-rprivate /mnt/data（rprivate 可阻断传播但保留原有挂载） - 确认无活跃依赖后，再尝试
sudo umount -l /mnt/data延迟卸载，避免因传播残留卡住
排查路径访问卡死是否由 NFS/CIFS 等网络挂载拖累
如果 bind mount 的源目录本身挂载的是 NFS、CIFS 等远程文件系统，且服务端失联或响应超时，那么任何对 bind 目标路径的操作（如 ls、stat）都可能阻塞数十秒甚至永久挂起，表现为“卡死”或“假死循环”。
- 运行
df -h /mnt/data看是否显示远程设备（如nfs-server:/export）；若是，检查网络连通性及服务端状态 - 用
timeout 3 ls /mnt/data测试响应时间，超时即提示底层挂载异常 - 紧急恢复可先取消远程挂载：
sudo umount -l /original/nfs/mount，再清理 bind mount
识别内核级阻塞而非用户态循环
真正的“死循环”通常伴随高 CPU 占用；而 bind mount 引发的卡死几乎总是 I/O 阻塞或 VFS 锁竞争，表现为进程状态为 D（uninterruptible sleep）。
- 执行
ps aux | grep -E "(D|U)" | grep "/mnt/data"找出状态为D的进程 - 查该进程堆栈：
cat /proc/<pid>/stack 2>/dev/null</pid>，若看到wait_on_page_bit、nfs_wait_bit_killable或do_mount相关调用，说明卡在内核挂载/读页逻辑 - 此时不要 kill -9，应优先用
umount -l解绑，让内核异步回收资源
