SPDK项目中NVMe/RDMA控制器删除时的死锁问题分析

在分布式存储系统中，SPDK（Storage Performance Development Kit）作为高性能存储开发工具包被广泛应用。近期在SPDK的NVMe over RDMA实现中发现了一个可能导致死锁的问题，本文将深入分析该问题的成因、影响及解决方案。

问题现象

当用户尝试删除vhost中的NVMe控制器时，系统会出现vhost进程卡死的现象。从日志中可以看到如下错误信息：

bdev_nvme.c:6229:bdev_nvme_delete_complete_poll: *ERROR*: NVMe path 'nvm-16udxfq48htf1-disk0' still exists after delete

通过gdb调试工具分析卡死的线程堆栈，发现线程阻塞在rdma_destroy_id函数调用处，这表明在销毁RDMA连接标识时发生了死锁。

技术背景

在SPDK的NVMe over RDMA实现中，每个I/O队列对(qpair)都关联一个RDMA连接标识。当删除NVMe控制器时，需要依次完成以下步骤：

1. 断开所有qpair的连接
2. 等待所有未完成的请求完成
3. 销毁RDMA资源

其中，RDMA通信管理器(CM)事件的处理是关键环节，包括连接建立、断开以及超时等事件。

问题根源分析

经过深入分析，发现问题源于以下两个关键因素：

1. 共享CM通道：所有qpair共享同一个CM通道，这意味着某个qpair的CM事件可能被其他I/O线程处理。例如，qpair A属于线程1，但其RDMA_CM_EVENT_TIMEWAIT_EXIT事件可能在线程2中被轮询到。

2. 竞态条件：在qpair状态变为NVME_RDMA_QPAIR_STATE_LINGERING时，没有正确获取控制器锁。这导致当某个线程正在销毁qpair时，另一个线程可能正在处理该qpair的CM事件，从而引发死锁。

解决方案

针对上述问题，SPDK社区提出了修复方案，核心思想是：

1. 确保在qpair状态变为NVME_RDMA_QPAIR_STATE_LINGERING时也获取控制器锁
2. 统一所有状态转换路径的锁保护机制

该修复方案已通过测试验证，能够有效解决删除NVMe控制器时的死锁问题。测试环境包括：

• 操作系统：AlmaLinux 9.1
• 内核版本：5.14.0-162.23.1.el9
• SPDK版本：v23.01

最佳实践建议

对于使用SPDK NVMe over RDMA功能的用户，建议：

1. 及时升级到包含该修复的SPDK版本
2. 在删除控制器前，确保所有I/O操作已完成
3. 监控系统日志中的NVMe路径删除错误信息
4. 对于关键业务系统，建议先在测试环境验证控制器删除操作

总结

SPDK作为高性能存储开发工具包，其稳定性和可靠性对存储系统至关重要。本次发现的NVMe/RDMA控制器删除死锁问题，通过深入分析CM事件处理机制和锁保护范围，最终找到了有效的解决方案。这体现了开源社区协作解决复杂技术问题的价值，也为用户提供了更稳定的存储基础设施。

对于仍在使用旧版本的用户，建议尽快升级到修复版本，以避免潜在的系统稳定性问题。同时，在设计和实现类似分布式存储系统时，需要特别注意资源共享场景下的线程安全和竞态条件问题。