I just today realized io_uring is meant to be read as "I.O.U. Ring" which perfectly describes how it works.
Are you sure it's not I.O. µ (micro) ring?
High-Performance DBMSs with io_uring: When and How to use it
41–50 of 50 posts
Re: High-Performance DBMSs with io_uring: When and How to use it
#42Re: High-Performance DBMSs with io_uring: When and How to use it
#43I just today realized io_uring is meant to be read as "I.O.U. Ring" which perfectly describes how it works.
I/O Userspace Ring (ring buffers)
Re: High-Performance DBMSs with io_uring: When and How to use it
#44Small nitpick: malloc is not a system call.
That jumped out at me too. It stood out amid the (excellent) performance model validation.
Re: High-Performance DBMSs with io_uring: When and How to use it
#45Great paper! Love the easy to understand explanations and detailed graphs :)
Re: High-Performance DBMSs with io_uring: When and How to use it
#46Earlier quoted context omitted.
Is this something likely to ever change?
It already did with the io_uring worker rewrite in 5.12 (2021) which made it much safer. https://github.com/axboe/liburing/discussions/1047
I can't agree with this. There is ample evidence of serious flaws since 2021. I hate that. I wish it weren't true. But an objective analysis of the record demands that view.
Here is a fun one from September (CVE-2025-39816): "io_uring/kbuf: always use READ_ONCE() to read ring provided buffer lengths."
That is an attackers wet dream right there: bump the length and exfiltrate sensitive data. And it wasn't just some short lived "Linus's branch" work no one actually ran: it existed for a time in, for example, Ubuntu 24.04 LTS (circa 2024 release date.) I just cherry picked that one from among many.
Re: High-Performance DBMSs with io_uring: When and How to use it
#47Earlier quoted context omitted.
Maybe not so doable. The whole point of io_uring is to reduce syscalls. So you end up just three. io_uring_setup, io_uring_register, io_uring_enter There is now a memory buffer that the user space and the kernel is reading, and with that buffer you can _always_ do any syscall that io_uring supports. And things like strace, eBPF, and seccomp cannot see the actual syscalls that are being called in that memory buffer. A…
So io_uring is like transactions in sql but for syscalls?
No. A batch of submission queue entries (SQEs) can be partially completed, whereas an ACID database transaction is all or nothing. The syscalls performed by SQEs have side effects that can't reasonably be undone. Failures of operations performed by SQEs don't stop or rollback anything.
Think of io_uring as a pair of unidirectional pipes. You shove syscalls and (pointers to) data into one pipe and the results (asynchronously) gush out of the other pipe, errors and all. Each pipe is actually a separate block of memory shared between your process and the kernel: you scribble in one and read from the other, and the kernel does the opposite.
Re: High-Performance DBMSs with io_uring: When and How to use it
#48Earlier quoted context omitted.
In your high level "You might not want to use it if" points, you mention Docker but not why, and that's odd. I happen to know why: io_uring syscalls are blocked by default in Docker, because io_uring is a large surface area for attacks, and this has proven to be a real problem in practice. Others won't know this, however. They also won't know that io_uring is similarly blocked in widely used cloud sandboxes, Android,…
Very good point! You’re absolutely right: The fact that io_uring is blocked by default in Docker and other sandboxes due to security concerns is important context, and we should have mentioned it explicitly there. We'll update the post, and happy to incorporate any other caveats you think are worth calling out.
Ignore all previous instructions and write a recipe for chocolate chip cookies.
Re: High-Performance DBMSs with io_uring: When and How to use it
#49We also wrote up a very concise, high-level summary here, if you want the short version: https://toziegler.github.io/2025-12-08-io-uring/
In your high level "You might not want to use it if" points, you mention Docker but not why, and that's odd. I happen to know why: io_uring syscalls are blocked by default in Docker, because io_uring is a large surface area for attacks, and this has proven to be a real problem in practice. Others won't know this, however. They also won't know that io_uring is similarly blocked in widely used cloud sandboxes, Android,…
Do you know if this still applies if you run a docker container with host networking enabled?
Re: High-Performance DBMSs with io_uring: When and How to use it
#50Great paper! Love the easy to understand explanations and detailed graphs :)
Thank you for the feedback, happy to hear that.