lsr: ls with io_uring

Locales also bring in a lot more complicated sorting - so that could be a factor also.

I don't agree that it was a reasonable tradeoff. Making an unreliable system emulate a reliable one is the very thing I find to be a bad idea. I don't think this is unique to NFS, it applies to any network filesystem you try to present as if it's a local one.

> What does vi do when the server hosting the file you're editing stop responding? None of these tools have that kind of error handling.

That's exactly why I don't think it's a good idea to just pretend a network connection is actually a local disk. Because tools aren't set up to handle issues with it being down.

Contrast it with approaches where the client is aware of the network connection (like HTTP/GRPC/etc)... the client can decide for itself how long it should retry failed requests, whether it should bubble up failures to the caller, or work "offline" until it gets an opportunity to resync, etc. With NFS the syscall just hangs forever by default.

Distributed systems are hard, and NFS (and other similar network filesystems) just pretend it isn't hard at all, which is great until something goes wrong, and then the abstraction leaks.

(Also I didn't say io_uring solves this, but I'm curious as to whether its performance would be any better than blocking calls.)

Bat did 445 syscall Cat did 48 syscall

Sure bat does beautify some things a lot but still I just wanted to tell this, I want something that can use io_uring for cat too I think,

like what's the least number of syscalls that you can use for something like cat?

The *context() family of formerly-POSIX functions (clownishly deprecated as “use pthreads instead”) is essentially a full implementation of stackful coroutines. Even the arguable design botch of them preserving the signal mask (the reason why they aren’t the go-to option even on Linux) is theoretically fixable on the libc level without system calls, it’s just a lot of work and very few can be bothered to do signals well.

As far as stackless coroutines, there’s a wide variety of libraries used in embedded systems and such (see the recent discussion[1] for some links), which are by necessity awkward enough that I don’t see any of them becoming broadly accepted. There were also a number of language extensions, among which I’d single out AC[2] (from the Barrelfish project) and CPC[3]. I’d love for, say, CPC to catch on, but it’s been over a decade now.

[1] https://news.ycombinator.com/item?id=44546640

[2] https://users.soe.ucsc.edu/~abadi/Papers/acasync.pdf

[3] https://www.irif.fr/~jch/research/cpc-2012.pdf

But for lsr, it's 9.34. The other tools have factors close to 10.09 or higher. Since ls has to sort it's output (unless -F is specified) I'd not be too surprised with a little superlinearity.

https://docs.google.com/spreadsheets/d/1EAYua3B3UeTGBtAejPw2...

Nit: an allocator is not a "memory model", and I very much want the memory model to not change under my feet.

in libraries. if youre just writing a final product it's totally fine to pick one and use it everywhere.

> std.heap.page_allocator

strongly disrecommend using this allocator as "default", it will take a trip to kernelland on each allocation.

You should basically only use the page allocator if you're writing another allocator.

I didn't notice when I read the article though. The original commenter is being pedantic.

These are actual discovered vulnerabilities, typically assigned CVEs and often exploited in sandbox escapes or privilege escalations: 1. CVE-2021-3491 (Kernel 5.11+)

    Type: Privilege escalation

    Mechanism: Failure to check CAP_SYS_ADMIN before registering io_uring restrictions allowed unprivileged users to bypass sandboxing.

    Impact: Bypass of security policy mechanisms.

    Type: UAF (Use-After-Free)

    Mechanism: io_uring allowed certain memory structures to be freed and reused improperly.

    Impact: Local privilege escalation.

    Type: Race condition

    Mechanism: A race in the io_uring timeout code could lead to memory corruption.

    Impact: Arbitrary code execution or kernel crash.

    Type: UAF and out-of-bounds access

    Impact: Escalation from containers or sandboxed processes.

    Tools like io_uring_shock and custom kernel exploits often target io_uring in container escape scenarios (esp. with Docker or LXC).

These are not necessarily exploitable today, but reflect deeper systemic design risks or assumptions. 1. Shared Memory Abuse

    io_uring uses shared rings (memory-mapped via mmap) between kernel and user space.

    Risk: If ring buffer memory management has reference count bugs, attackers could force races, data corruption, or misuse stale pointers.

 2. User-Controlled Kernel Pointers

    Some features allow user-specified buffers, SQEs, and CQEs to reference arbitrary memory (e.g. via IORING_OP_PROVIDE_BUFFERS, IORING_OP_MSG_RING).

    Risk: Incomplete validation could allow crafting fake kernel structures or triggering speculative attacks.

 3. Speculative Execution & Side Channels

    Since io_uring relies on pre-submitted work queues and long-lived kernel threads, it opens timing side channels.

    Risk: Predictable scheduling or timing leaks, esp. combined with hardware speculation (Spectre-class).

 4. Bypassing seccomp or AppArmor Filters

    io_uring operations can effectively batch or obscure syscall behavior.

    Example: A program restricted from calling sendmsg() directly might still use io_uring to perform similar actions.

    Risk: Policy enforcement tools become less effective, requiring explicit io_uring filtering.

 5. Poor Auditability

    The batched and asynchronous nature makes logging or syscall audit trails incomplete or confusing.

    Risk: Harder for defenders or monitoring tools to track intent or detect misuse in real time.

 6. Ring Reuse + Threaded Offload

    With IORING_SETUP_SQPOLL or IORING_SETUP_IOPOLL, I/O workers can run in kernel threads detached from user context.

    Risk: Desynchronized security context can lead to privileged operations escaping sandbox context (e.g., post-chroot but pre-fork).

 7. File Descriptor Reuse and Lifecycle Mismatch

    Some operations in io_uring rely on fixed file descriptors or registered files. Race conditions with FD reuse or closing can cause inconsistencies.

    Risk: UAF, type confusion, or logic bombs triggered by kernel state confusion.

 Emerging Threat Vectors
 eBPF + io_uring

    Some exploits chain io_uring with eBPF to do arbitrary memory reads or writes. e.g., io_uring to perform controlled allocations, then eBPF to read or write memory.

 io_uring + userfaultfd

    Combining userfaultfd with io_uring allows very fine-grained control over page faults during I/O — great for fuzzing, also for exploit primitives.

Other replies lead me to believe it's not worth doing though, that it would not actually save syscalls and might make things worse.

which certainly is a valid way or prioritizing. similarly, distros/users may prioritize stability, which means the theoretical improvement would now be stuck in not-used-land. the value of software appears when it's run, not when it's written