Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Concurrent writers can grow a file past RLIMIT_FSIZE

Aperta
  • Qualcosa non va?
#464 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 3 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
c, linux, macos
Ambito
operating-systems

Direzione di ricerca

Start with fsize_room and fsize_limit_write in src/syscall/io.c, then trace their callers for descriptor-position writes, O_APPEND, and offsetless sendfile or splice. The issue requires coordination across threads, forked processes, and independent opens without colliding with guest locks; read the linked discussion on #435 and #463 for context. Done means concurrent regular-file writes cannot grow the file past a finite RLIMIT_FSIZE.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

bug

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 (https://github.com/sysprog21/elfuse/pull/435#discussion_r4245829599) and again on #463 (https://github.com/sysprog21/elfuse/pull/463#discussion_r4362471747).

Lingua principale
C
Stelle
275
Fork
29
Merge medio
2g 22h
PR unite (30g)
18

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di sysprog21/elfuse

Tutte le issue di sysprog21/elfuse

Issue simili

Altre issue su C

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.