I'm the author and I'm not native speaker, so please bear that in mind. However, I admit I've used AI for grammar and style. IMHO, the post is not fiction, I just wanted to communicate the ideas as clearly and effectively as possible.
TBH I don't think it's that bad: the article is not hard to read and pretty informative (and is not just a copy + paste from a prompt), it's just got a hint of that tone which can grate just because it's rendered so cliche by LLM writing.
Thank you, that's actually was my actual attitude: found interesting things -> used AI to polish notes and quick draft -> "Hey folks, here is a cool thing I've found".
The asynchronous behaviour raises interesting questions as to whether or not this is a bug or working as intended, and whether or not the io_uring API should offer controls to allow the calling application to decide.
With synchronous intra-machine calls we mostly take it for granted that pending modifications die with the caller.
But with inter-machine communications we mostly take it for granted that the sending machine and its entire local area can disappear and operations it sent will complete.
Of course, there are exceptions, especially when APIs/systems offer atomicity, consistency checks, etc.
But without express design intent, or preferably caller intent, one can argue both sides of the asynchronous intra-machine case and be right.
I guess my thinking isn't so much that this happens as that it happens implicitly.
If it's truly asynchronous, I don't see the issue with IO being decoupled from process lifetime.
If you wanted to stop the IO at process death, the mechanism needed for this would introduce an overhead that would likely slow things down in general.
Note, that this also includes retaining process memory related to the I/O. In my experiment I used regular 4 KiB pages, which is smaller or equal to the I/O block size. However, in case of huge pages only a small fraction can be I/O related. And I suppose, that this small part would pin the whole page, which might have some sensitive information. Still protected, however, but who knows.
Can you explain your thinking? As an extreme example you could have a "write backdoored .bashrc, then wait 5 minutes" repeated a thousand times queued as async i/o. If malware did this you couldn't just kill the process to stop it. You would have to shutdown the machine.
Typically there is also a latency trade off, so you can choose security and performance while losing latency. Systems should not depend on processes being fast to terminate anyways so making it slower in this case is fine.
Unrelated: My cat died. Saddest day of my life. I watched the light leave his eyes and still wondered where he went.
I looked it up and it said that the last thing to go when dying is probably your hearing.
When you die, typically you lose your sight first, then your bodily sensations, and 1-by-1 all your sensory channels turn off: Balance, equilibrium, proprioception, until you are like an empty force flying through infinite darkness, all your thoughts still in tact, knowing what is happening to you, and in the background you can still hear everyone in the room, until the sounds too begin to fade and distort into a light buzzing noise that gets higher and higher pitched like a zipper zipping up your last waking experience in a metaphorical body bag to be tossed off the edge of time.
i bet if you mmap'd a big file and then dirtied a ton of pages and then exited and watched the file on disk, you'd see writes occurring after the process exits as well.
25 comments
[ 2.0 ms ] story [ 27.2 ms ] thread> These are measured results backed by the Linux source, not a portable guarantee for every kernel, filesystem, device, or API called “AIO”.
> The interesting race window is there, but hard to see. So I made it larger.
With synchronous intra-machine calls we mostly take it for granted that pending modifications die with the caller.
But with inter-machine communications we mostly take it for granted that the sending machine and its entire local area can disappear and operations it sent will complete.
Of course, there are exceptions, especially when APIs/systems offer atomicity, consistency checks, etc.
But without express design intent, or preferably caller intent, one can argue both sides of the asynchronous intra-machine case and be right.
I guess my thinking isn't so much that this happens as that it happens implicitly.
If you wanted to stop the IO at process death, the mechanism needed for this would introduce an overhead that would likely slow things down in general.
The meltdown+spectre saga showed this for speculative execution. This is no different.
Unrelated: My cat died. Saddest day of my life. I watched the light leave his eyes and still wondered where he went.
I looked it up and it said that the last thing to go when dying is probably your hearing.
When you die, typically you lose your sight first, then your bodily sensations, and 1-by-1 all your sensory channels turn off: Balance, equilibrium, proprioception, until you are like an empty force flying through infinite darkness, all your thoughts still in tact, knowing what is happening to you, and in the background you can still hear everyone in the room, until the sounds too begin to fade and distort into a light buzzing noise that gets higher and higher pitched like a zipper zipping up your last waking experience in a metaphorical body bag to be tossed off the edge of time.