Concurrent writers can grow a file past RLIMIT_FSIZE #464

Background

#463 enforces RLIMIT_FSIZE on regular-file writes. A write that goes by the descriptor's own position reads that position, sizes itself against the limit, and then the host writes at whatever the position is by then. The affected calls are write, writev, an O_APPEND descriptor, pwritev2 with RWF_APPEND, and sendfile or splice with no output offset. Two writers on one open file description can each fit the same remaining room, so the file ends past the limit by at most one write per extra writer. An O_APPEND writer has the same window even without a shared description: two writers that each opened the file with O_APPEND both size themselves against the current file size. pwrite and pwritev at an explicit offset are not affected, because each lands inside the limit by its own arithmetic.

Linux behavior

Linux has no such window: the size check in generic_write_checks and the write run under the inode lock (inode_lock in generic_file_write_iter), so concurrent writers see each other's growth.

Goal

A guest under a finite RLIMIT_FSIZE cannot grow a regular file past the limit, however many threads or processes write to it at the same time, through one open file description or through separate ones opened with O_APPEND.

Constraints

• A mutex inside one elfuse process covers threads only. Fork children are separate host processes that share the host file description, so the serialization has to reach across the fork family. Separate O_APPEND opens can come from unrelated processes, two independent elfuse invocations included, so it has to coordinate on the file itself.
• A host flock or fcntl lock on the guest's file would collide with the guest's own locks on it.

Evidence

This is from reading the code on #463 (fsize_room and fsize_limit_write in src/syscall/io.c, and their callers), not from a measured run; a reproducer depends on two writers landing in the window. First raised on #435 (#435 (comment)) and again on #463 (#463 (comment)).