If I understand correctly, the issue is mutex on file objects at the kernel level. Basically it is a failing of the implementation of the "file" abstraction. Or perhaps a failing of the "file" abstraction itself?

Per Wikipedia [0] (because I had no idea what a TOCTTOU race condition was)

    In the context of file system TOCTOU race conditions, the fundamental challenge is ensuring that the file system cannot be changed between two system calls. In 2004, an impossibility result was published, showing that there was no portable, deterministic technique for avoiding TOCTOU race conditions.[9]

    Since this impossibility result, libraries for tracking file descriptors and ensuring correctness have been proposed by researchers.

I was curious to see how a different abstraction would avoid this problem. Plan 9 FS appears to have had this issue at one point [1], but notably not because of the FS implementation itself. Rather the problem was caused by the underlying system's executing outside of the P9FS ordered access to a given file (someone please tell me if my understanding is incorrect).

Here's an article that talks about the problems of this (and other) race conditions from the level of abstraction [2].

NOTE: I'm not claiming that P9FS is immune from this sort of attack, I'm only commenting on what I've found.

[0] https://en.wikipedia.org/wiki/Time-of-check_to_time-of-use

[1] https://bugs.launchpad.net/qemu/+bug/1911666

[2] https://gavinhoward.com/2020/02/computing-is-broken-and-how-...