Io_uring support rocky 9.3

Red Hat has already supported io_uring in RHEL 9.3. According to the Red Hat documentation, the related system calls may either succeed or return EPERM. However, I received ENOSYS on Rocky 9.3.

You’ve not provided enough information on your issue. You must be running at least kernel 5.14.0-362.8.1.el9_3.x86_64 on your system for io_uring.

If you feel it’s an issue or a bug with our builds, please report it to bugs.rockylinux.org with all the relevant information, such as reproduction steps, logs, and other relevant system configuration.

I don’t know where the problem occurred, but I can confirm that my kernel version is fine.(5.14.0-362.13.1.el9_3.x86_64) My question is whether Rocky Linux currently supports io_uring?Has it passed the CI tests?

Are you sure? You said you got ENOSYS. What are you doing that would generate that?

This shows it’s supported.

[root@xmpp01 ~]# grep -i uring /boot/config-$(uname -r)
CONFIG_IO_URING=y
[root@xmpp01 ~]# grep io_uring_setup /proc/kallsyms
ffffffffa61d35c0 t __pfx_io_uring_setup
ffffffffa61d35d0 t io_uring_setup
ffffffffa61d3660 T __pfx___ia32_sys_io_uring_setup
ffffffffa61d3670 T __ia32_sys_io_uring_setup
ffffffffa61d36f0 T __pfx___x64_sys_io_uring_setup
ffffffffa61d3700 T __x64_sys_io_uring_setup
ffffffffa6816287 t io_uring_setup.cold
ffffffffa7cb0140 d event_exit__io_uring_setup
ffffffffa7cb01e0 d event_enter__io_uring_setup
ffffffffa7cb0280 d __syscall_meta__io_uring_setup
ffffffffa7cb02c0 d args__io_uring_setup
ffffffffa7cb02d0 d types__io_uring_setup
ffffffffa84b9aa8 d __event_exit__io_uring_setup
ffffffffa84b9ab0 d __event_enter__io_uring_setup
ffffffffa84bbb78 d __p_syscall_meta__io_uring_setup
ffffffffa84bfb10 d _eil_addr___ia32_sys_io_uring_setup
ffffffffa84bfb20 d _eil_addr___x64_sys_io_uring_setup

[root@xmpp01 ~]# cat ex.c
#include <errno.h>
#include <linux/io_uring.h>
#include <stddef.h>
#include <sys/syscall.h>
#include <unistd.h>
#include <stdio.h>

int main(int argc, char **argv) {
  if (syscall(__NR_io_uring_register, 0, IORING_UNREGISTER_BUFFERS, NULL, 0) && errno == ENOSYS) {
    printf("Not available\n");
  } else {
    printf("Available\n");
  }
}
[root@xmpp01 ~]# gcc -o test ex.c
[root@xmpp01 ~]# ./test
Available

It doesn’t seem to be a kernel issue. I’m running a test program inside a podman container and getting ENOSYS. Running it directly on the host does return 0.

This is most likely due to default limitations in docker containers for security reasons. There is something about it here: Allow containers access to `io_uring` syscalls · Issue #16796 · containers/podman · GitHub

Someone there suggests running the container with:

--security-opt seccomp=unconfined

alternatively as also suggested towards the end of the thread because of the security risks allowing everything using the above command, would require you to create your own seccomp.

More precisely, this is a security vulnerability in seccomp itself, which cannot filter system calls indirectly invoked by io_uring.