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 小时，以是定位它就变得很困难及费事。