Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
From:   Joshua Hudson <joshudson@gmail.com>
Date:   Mon, 3 Jun 2019 08:24:44 -0700
Message-ID: <CA+jjjYT6_ZZP5Ucqxvtmcd3d18vAC1LRtruiXojFVaxpJ-HhLA@mail.gmail.com>
Subject: O_CLOFORK use case
To:     linux-kernel <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

I ran headlong into the use case for O_CLOFORK and got into a locking
debate over it.

The actual use case involves squashing a thread race between two
threads. If a file is opened for write in one thread with O_CLOEXEC
while another thread calls fork(), a race condition can happen where
the thread that closes the handle misses the out of disk error because
the child process closed the handle last inside execve().

The decades old idiom for replacing config files isn't safe in
multi-threaded code. Yipe.

    int h = open(".configfile~", O_WRONY | O_EXCL | O_CLOEXEC, 0666);
    if (h < 0) { perror(".configfile"); return 1; }
    ssize_t delta = 0;
    while ((delta = write(h, newconfigdata, newconfiglen)) > 0) {
        newconfigdata += delta;
        newconfiglen -= delta;
    }
    if (delta < 0) { perror(".configfile"); return 1; }
    if (close(h)) { perror(".configfile"); return 1; }
    rename(".configfile~", ".configfile");

To fix it, we have to put locks around close() and fork()/vfork(). Ugh.