Linux !ko/5.17-BBRplus AMD64（X86_64）内核致命的 futex_wait 函数死锁问题。

!ko 表示系统内核（system-kernel）

致命：

在 CentOS（RedHat）、Ubuntu、Debian 等多个发行版本 Linux 操作系统上，若人们升级 5.17-BBRplus 版本内核，那么在应用程式频繁的 futex_wait（syscall）等待唤醒时，或会存在 futex_wait 函数发生死锁的疑难问题。

LMP：

futex(2) - Linux manual page (man7.org)

注意：

该问题发生时，应用程序将无法被 KILL -9、系统无法回收进程资源，且若运行在 screen 之中，则 screen 无法被关闭，产生僵尸进程，持续耗费设备硬件及内存资源，直到设备系统被重启。

即为：

该问题常见于，基于 EPOLL、IO-URING 结构，且多线程驱动的应用程序（基于事件/消息驱动模型）。

或应用程式多线程时，大量使用，例如： pthread_mutex_lock，其底层实现通过 syscall 系统调用 futex（内核同步）。

额外补充一点，产生致命问题还有一个附加条件：

A：设备须为多个CPU核，而非一个CPU核，单个CPU核上，并未发现存在该问题。

解决办法：

采用发行版默认的内核版本，例如：5.4、6.1.4 ... 

后记：

该问题在本人一个开源项目工具之中被发现，我本人持续追踪了该问题且尝试进行应用层修复，大约耗费两个月左右把。

起初以为是应用程序本身的问题，把可能会导致该问题发生（deadlock）的地方，全部重新编写，但仍旧没有解决它。

所以，耗费了大量的精力去分析代码本身是否存在，设计之外的疑难问题漏洞，这包含对三方库（依赖项）源代码的细致探索及分析。

并且鉴于，该问题并非是，必定重现的小问题，它复现需要程序稳定工作、且交换大量的数据吞吐量，才有一定的概率性复现，即：至少需要先跑 7*24 小时，所以定位它就变得很困难及费事。