3 ms·
> but the one here is that it's being used incorrectly Being ALLOWED to be used badly, is the major cause of unsafety. And consider that all the reports you
by mamcx 2y ago
> but the one here is that it's being used incorrectly
Being ALLOWED to be used badly, is the major cause of unsafety.
And consider that all the reports you reply to are by serious teams. NOT EVEN THEM succeed.
That is the #1 definition of
> something wrong with io_uring itself
- zbentley 2y agoStrongly disagree. At the level of io_uring (syscalls/syscall orchestration), it is expected that available tools are prone to mis-use, and that libraries/higher layers will provide abstractions around them to mitigate that risk. This isn't like the Rust-vs-C argument, where the claim is that you should prefer the option of two equivalently-capable solutions in a space that doesn't allow mis-use. This is more like assembly language, or the fact that memory inside kernel rings is flat and vulnerable: those are low-level tools to facilitate low-level goals with a high risk of mis-use, and the appropriate mitigation for that risk is to build higher-level tools that intercept/prevent that mis-use.
- eqvinox 2y agoFull ACK. To bring it back to the FD leak in the original post: the kernel won't stop you from forgetting to call close() either, io_uring or no.
- cryptonector 2y ago> Being ALLOWED to be used badly I don't see how you stop devs from using a system call or similar incorrectly. In this case the result is an FD leak, which is no more than a DoS, and easy to chase and fix [unless the library in question is designed in such a way that the problem is unfixable, in which case abandon that library].