are filesystems on linux just safer than the network subsystems or do filesystems just never expose any interface besides posix i/o so they have a much smaller and better-characterized attack surface?
Post
Replies:
15
Boosts:
14
i do wish memcpy in the kernel could somehow be cast asynchronously and receive an async result
that would require the processor to have a request/response flag system but it would not be a goddamn event loop
splice() shouldn't be a page mapping operation because it shouldn't occur in a single synchronous call. you should have to inform the kernel beforehand of your intent to splice
it loses more latency through a ring buffer but here's the thing if you can losslessly represent the dependency graph between operations in the kernel you don't need to do anything synchronously. just let your action graph swell from one process execution and then identify the paths necessary to resolve the new set of action dependencies. will probably require a model of expected runtime for each data motion operation........this sounds hard but actually doable
i did notice that io_uring required you to register files and buffers to avoid thrashing every time you read from an fd and i was like wowwwwwwww if only there were some magical way to provide task-local scratch space to the kernel that avoided thrashing by putting the task to sleep
legitimately i feel libc would be easier than posix i/o since i'm guessing that fread/fwrite do not require instantaneously broadcasting data through the page cache since i believe they have their own buffers. i'll go check posix grumble
posix has personally wronged me since the day i learned inodes were a sick joke. i then learned every filesystem dutifully provides an inode to posix APIs and not a single one of them have ever considered making it useful and i realized every filesystem developer is my enemy and the enemy of all i/o operations
hilarious that FIPS imposes requirements upon posix write() return values and not like eventually consistent persistence semantics. cryptography doesn't care about the contents of your hard drive, just the quality of your character streams
amazed that libc fwrite has the fflush call to sync in-mem state as well as feof/ferror. it's deeply annoying to me that posix requires every file to be a globally mutable shared memory mapping and every write to be unbuffered. that's fucked up! who asked for this?
why would you make a portable operating system interface specification that isn't portable
no wonder nobody does microkernels. what's the point of an isolation boundary
@julia is this why posix sux or am i missing more reasons. learning that posix is why filesystems are all boring and can't do inodes is radicalizing
fucking amazing that section 4.15.1.1 Data Races does not mention THE FUCKING PAGE CACHE
i don't understand how the page cache doesn't have a data race if a file write is not defined as an atomic operation
they just don't care
After a write() to a regular file has successfully returned:
Any successful read() from each byte position in the file that was modified by that write shall return the data specified by the write() for that position until such byte positions are again modified.
Any subsequent successful write() to the same byte position in the file shall overwrite that file data.
i'm not just getting stuck in the wording i also believed that a data race i.e. UB was supposed to result from cross-thread access to the same memory location without atomicity
