Linux io_uring_disabled 设置变化会影响哪些进程

Linux 的 io_uring_disabled 控制的是“能不能创建新的 io_uring 实例”，不是把所有正在使用 io_uring 的进程立刻杀掉。值为 0 时正常创建；值为 1 时，未授权进程创建会收到 -EPERM，但具备 CAP_SYS_ADMIN 或符合 io_uring_group 规则的进程仍可创建；值为 2 时，所有新建请求都会失败。已经创建的实例仍可继续使用。

先把 io_uring_disabled 的三个值对上权限边界

排查时先保留当前值和组策略。下面的命令只读参数，不会改变内核状态：

# 记录当前的创建策略，便于修改后比较并恢复
printf 'io_uring_disabled='; cat /proc/sys/kernel/io_uring_disabled
printf 'io_uring_group='; cat /proc/sys/kernel/io_uring_group

# 查看当前 shell 是否具备系统管理能力
capsh --print | grep -E 'Current:|cap_sys_admin' || true

可以把判断压缩成一张表。io_uring_group 为 -1 时，值为 1 的额外放行对象只剩具备 CAP_SYS_ADMIN 的进程；若内核把某个组配置为允许组，则组成员才有创建资格。

设置变化真正打到的是哪些进程

最容易误判的场景是：服务已经启动，管理员把值从 0 改成 1，随后一次热重载报权限错误。这个错误通常发生在重载代码再次创建 ring，而不是原来的 ring 被内核收回。

因此要按“创建动作”定位进程：首次启动、worker 扩容、连接池重建、热重载和故障恢复路径，都可能重新调用 io_uring_setup()。同一个进程如果已经有旧实例，继续提交和收割请求通常不因该 sysctl 改变而自动失效；但它之后再申请第二个实例，仍要重新经过当前策略。

值为 2 时，特权也不能绕过新建限制。若依赖 io_uring 的程序把 EPERM 当成不可恢复错误，服务可能启动失败；若程序实现了回退到传统同步 I/O 或其他异步后端，则可能只是性能路径变化。这个差异应在应用日志和启动配置中确认，不能仅凭参数名推断。

修改前后怎么做一轮可恢复检查

临时调整可以先在目标主机上完成，并把旧值写进变更记录。不要一上来写入永久配置：

# 保存旧值，变更失败时按原值恢复
old_value=$(cat /proc/sys/kernel/io_uring_disabled)
echo "old io_uring_disabled=$old_value"

# 只改变当前运行内核；生产环境先在灰度主机验证
sudo sysctl -w kernel.io_uring_disabled=1

# 再读一次，确认写入的是预期值
sysctl kernel.io_uring_disabled kernel.io_uring_group

验证对象至少包括：一个普通服务账号的新进程、需要扩容的 worker、已有实例的持续请求，以及应用遇到 EPERM 时是否有明确回退。若要恢复临时状态，使用变更记录中的旧值：

# 仅恢复本次运行时配置，不改动磁盘上的 sysctl 文件
sudo sysctl -w kernel.io_uring_disabled="$old_value"

确认灰度结果后，再把目标值放入发行版实际加载的 sysctl 配置文件，并在重启或配置管理流程中复核。不同发行版的文件布局可能不同，关键是确认最终加载来源，而不是只改某个同名文件。

常见问题

把 io_uring_disabled 改成 1 会让现有服务立刻中断吗？

不会直接销毁既有 io_uring 实例。服务后续若需要创建新实例，才会按新的权限规则判断。

值为 1 时为什么 root 能创建而普通账号失败？

内核文档规定值为 1 会检查特权或允许组。普通账号既没有对应能力，也不在允许组时，io_uring_setup() 返回 -EPERM。

值为 2 时给进程加 CAP_SYS_ADMIN 有用吗？

没有。值为 2 对所有进程禁止创建新实例，能力提升不能绕过这条更严格的全局策略。