[luizfelberti]

A bit dated in the sense that for Linux you'd probably use io_uring nowadays, but otherwise it's a timeless design

Still, I'm conflicted on whether separating stages per thread (accept on one thread and the client loop in another) is a good idea. It sounds like the gains would be minimal or non-existent even in ideal circumstances, and on some workloads where there's not a lot of clients or connection churn it would waste an entire core for handling a low-volume event.

I'm open to contrarian opinions on this though, maybe I'm not seeing soemthing...

[raggi]

It’s not a good idea and that’s where I’d really start with the dated commentary here rather than focusing on the polling mechanism. It depends on the application but if the buffers are large (>=64kb) such as a common TCP workload then uring won’t necessarily help that much. You’ll gain a lot of scalability regardless of polling mechanism by making sure you can utilize rss and xss optimizations.

[wild_egg]

It's been a while but why is uring not helpful for larger buffers? I'd think the zero-copy I/O capabilities would make it more helpful for larger payloads, not less

[Veserv]

uring supports zero-copy, but is not a copy-reduction mechanism; it is a syscall-reduction mechanism. Large buffers mean less syscalls to start with, so less benefit.

[raggi]

Exactly this. The kernel alloc’d buffers can help but if that was a primary concern you’re in driver territory. Anything still userspace kind of optimization domain the portion of syscalls for large buffers in a buffered flow is heavily amortized and not overly relevant.

[jfindley]

io_uring is in a curious place. Yes it does offer significant performance advantages, but it continues to be such a consistent source of bugs - many with serious security implications - that it's questionable if it's really worth using.

I do agree that it's a bit dated and today you'd do other things (notably SO_REUSEPORT), just feel that io_uring is a questionable example.

[ciconia]

> continues to be such a consistent source of bugs - many with serious security implications... just feel that io_uring is a questionable example.

Are you saying this as someone with experience, or is it just a feeling? Please give examples of recent bugs in io_uring that have security implications.

[jfindley]

There are a couple of notable examples of projects[0] and companies[1] that have got tired of it, and no longer use it.

There's considerable difficulty these days extrapolating "real" vulnerabilities from kernel CVEs, as the kernel team quite reasonably feel that basically any bug can be a vulnerability in the right situation, but the list of vulnerabilities in io_uring over the past 12 months[2] is pretty staggering to me.

0: https://github.com/containerd/containerd/pull/9320 1: https://security.googleblog.com/2023/06/learnings-from-kctf-... 3: https://nvd.nist.gov/vuln/search#/nvd/home?offset=0&rowCount...

[dspillett]

Not OP, and I'm no expert in the area at all, but I _do_ have a feeling that there have been quite a few such issues posted here and elsewhere that I read in the last year.

https://www.cve.org/CVERecord/SearchResults?query=io_uring seems to back that up. Only one relevant CVE listed there for 2026 so far, for more than two per month on average in 2025. Caveat: I've not looked into the severity and ease of exploit for any of those issues listed.

[pocksuppet]

Did you read the CVEs? Half these aren't vulnerabilities. One allows the root user to create a kernel thread and then block its shutdown for several minutes. One is that if you do something that's obviously stupid, you don't get an event notification for it.

Remember the Linux kernel's policy of assigning a CVE to every single bug, in protest to the stupid way CVEs were being assigned before that.

[dspillett]

> Did you read the CVEs?

You obviously didn't read to the end of my little post, yet feel righteous enough to throw that out…

> One allows the root user to create a kernel thread and then block its shutdown for several minutes.

Which as part of a compromise chain could cause a DoS issue that might be able to bypass common protections like cgroup imposed limits.

[nine_k]

If we apply risk/reward analysis, how probable is such a chain of exploits? If you already got local root, you might as well do a little bit more than a simple DoS.

Depending on how much performance would be gained by using io_uring in a particular case, and how many layers of protection exist around your server, it might be a risk worth taking.

[jauntywundrkind]

In node.js I've seen time and time again some slow task that happens only every now and then, but which causes significant latency spikes. Having the one single event loop, with tasks big and small, from all stages of the processing pipeline mixed in, feels so crude. I really want a more sophisticated architecture where different stages of the execution can be managed independently.

I also want to mention that very very very few programs do, but io_uring does let you run multiple io_urings!! Your program can pick from which completion queue it wants to read, can put high priority tasks in a specific iou.

[eklavya]

It is not a good idea, especially with the new chiplet/CCX processors.