From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751937AbdJRPms (ORCPT ); Wed, 18 Oct 2017 11:42:48 -0400 Received: from relay01.pair.com ([209.68.5.15]:39815 "EHLO relay01.pair.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751846AbdJRPmq (ORCPT ); Wed, 18 Oct 2017 11:42:46 -0400 X-Greylist: delayed 576 seconds by postgrey-1.27 at vger.kernel.org; Wed, 18 Oct 2017 11:42:46 EDT To: linux-kernel@vger.kernel.org From: Ralph Corderoy Subject: Request for O_CLOFORK, akin to O_CLOEXEC. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Date: Wed, 18 Oct 2017 16:33:08 +0100 Message-Id: <20171018153308.363172158E@orac.inputplus.co.uk> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Please keep me CC'd. A multi-threaded program's thread A wants to create a new executable file with open(O_CLOEXEC), write, close, and then fork and exec it. Meanwhile, another thread B forks before A's close, carrying a reference to the open file description with it, thus A's execve fails with ETXTBUSY because the executable is still open for writing. open(O_CLOEXEC) write() fork() close() fork() execve(foo) -1 ETXTBUSY execve(bar) This is being seen in the wild, repeatedly. It bit Go five years ago and was workaround then with sleeps and retries. Java has a bug report from 2014 that has never been resolved. Recently, Go developers debugged the same problem, this time from testing where many binaries want to be written and executed; sleeping would drag down throughput. Google shows quite a few other ETXTBUSY reports where folks think they're closing the FD, but don't cotton on other forks are occasionally happening at just the wrong moment. Userspace coordination between threads to lock around close(), dup2(), and dup3(), that close an FD, and then manually closing FD_CLOEXEC ones before fork can be proposed, e.g. https://github.com/golang/go/issues/22315#issuecomment-337597575 but they assume that program has complete control over all FD closing and forks; not true with libraries also kicking off threads. Just as O_CLOEXEC was needed, it would seem O_CLOFORK is required that closes such FDs on fork, stopping another thread unwittingly carrying the FD with it. It has been independently mooted before without explaining why it was useful. [PATCH] fs: add FD_CLOFORK and O_CLOFORK https://lists.gt.net/linux/kernel/1375919 Feedback wanted. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy