Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Concurrent writers can grow a file past RLIMIT_FSIZE

オープン
  • 何か問題がありますか？
#464 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 3 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
c, linux, macos
領域
operating-systems

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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).

主要言語
C
スター
275
フォーク
29
平均マージ
2日 22時間
マージ済み PR（30日）
18

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

sysprog21/elfuse のほかの issue

sysprog21/elfuse の issue をすべて見る

似ている issue

C の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。