Lord of the Io_uring (2020)
unixism.net
Lord of the Io_uring (2020)
1–10 of 66 posts
Re: Lord of the Io_uring (2020)
#2Definitely one of the best pieces of documentation out there for io_uring. But I'm not sure how much if at all it's been updated since 2020 & Linux 5.5. https://web.archive.org/web/20200527021134/https://unixism.n...
Re: Lord of the Io_uring (2020)
#3But they were all of them deceived?
Re: Lord of the Io_uring (2020)
#4a lot of the functionality was significantly improved in 6 and isn't reflected there.
In practice io_uring can be used in many different ways, and it can be challenging to find the most efficient one.
Re: Lord of the Io_uring (2020)
#5But they were all of them deceived?
This made me laugh a lot. I can spot Tolkien's language from a mile off!
Re: Lord of the Io_uring (2020)
#6I'd like to use io_uring, but as long as it bypasses seccomp it should be disabled whenever seccomp is in use. As such, I use epoll, and find it annoying when kernel APIs like ublk require io_uring. The places I'd want to use ublk are inside sandboxes using seccomp. Given that container runtimes, hardened kernels, chromeos, etc., disable io_uring, using it means needing an epoll fallback anyways, so might as well just use epoll and not maintain two async backends for your application.
Re: Lord of the Io_uring (2020)
#7There are examples of cat and cp using io_uring. What are the chances of having io_uring utilised by standard commands to improve overall Linux performance? I presume GNU utils are not Linux specific hence such commands are programmed for a generic *nix.
Another one is I could not find a benchmark with io_uring - this would confirm the benefit of going from epoll.
Re: Lord of the Io_uring (2020)
#8I'd like to use io_uring, but as long as it bypasses seccomp it should be disabled whenever seccomp is in use. As such, I use epoll, and find it annoying when kernel APIs like ublk require io_uring. The places I'd want to use ublk are inside sandboxes using seccomp. Given that container runtimes, hardened kernels, chromeos, etc., disable io_uring, using it means needing an epoll fallback anyways, so might as well jus…
Is there a specific io_uring opcode you would like disabled in your sandboxes? It's not like io_uring is a complete seccomp bypass, just another syscall that provides an alternative way to do many things. I doubt you block "read" or "accept" in docker, for example. You can't execute a sysctl or mount a filesystem using io_uring, which are things that are actually blocked in Docker by default.
edit: on the other hand, a good reason to disable uring in containers is that it's infested with vulnerabilities. It's new, complex, and does a whole lot of things - all of which make serious security bugs there quite common right now.
Re: Lord of the Io_uring (2020)
#9a lot of the functionality was significantly improved in 6 and isn't reflected there. In practice io_uring can be used in many different ways, and it can be challenging to find the most efficient one.
What are the big changes in 6? links welcome.
Re: Lord of the Io_uring (2020)
#10But they were all of them deceived?
And nine, nine async I/O programming APIs were gifted to the race of Linux users, who above all else desire power.